Presently in the midst of taking the 50th annual two-week Human Factors Engineering short course offered by the University of Michigan, I find myself struck by parallels between HF and another domain in which I have non-trivial interest and knowledge, namely security. If you mingle in security research circles, you likely find two maxims oft repeated. First, “security is a process, not a product”. Second, “security has to be baked into a system”. Substitute “security” with “human factors” and one captures the frustrations of human factors engineers as voiced by many of the lecturers in my present course. Security experts dread having a “complete” system thrown over the wall to them with the odious task to “make the system secure”. Likewise HF folks chafe at the prospect of having a “complete” system tossed in their laps with the directive to “make it like the iPhone”. Given the (not so?) well known principle that fundamental defects become exponentially more expensive to repair as a project progresses, one marvels at the software development world’s need to have such independent “revelations” in various sub-disciplines.

The parallels do not end there. Practitioners of both subject matters have notorious difficulty quantifying costs, benefits, and risks. Leaky Abstractions furthermore pose myriad problems. As such, early and ongoing consideration seem the key to success. Iterative and Agile development practices are nothing new, but the industry regularly forgets to exert sufficient pressure on various sub-systems to shake out significant flaws before they become cripplingly expensive. User interfaces, security, networking, storage systems… As elegantly as we may modularize our systems, the inherent leakiness of abstraction boundaries between these sub-systems manages to burn us again and again. Consequently, we must aggressively and regularly conduct usability tests, performance tests, and penetration tests. One cannot overestimate the criticality of regular integration testing and sanity checking. Even seemingly simple systems are hard to get right.

— AWG