Let's treat technical architecture as an exercise in human-centered design, and learn from ergonmics and human-computer interaction.
NOTE: CURRENTLY IN RAMBLING DRAFT MODE! - TODO Add examples of human-centered principles and show the parallels
The stereotypical techie got into software because he (yes, "he") can't deal with people. If this is true, he chose the wrong business. Many techies have to deal with managers, clients, and analysts. But forget about them for now, because what I'm talking about is strictly t2t: techies dealing with other techies.
Even the most hardcore geek - the mythical beast fed pizza through a slot in the door - interacts with techies. In some cases, he may actually talk to them. In all cases, he is writing software which will have to be understood by an audience of techies, even if the audience consists of himself at a later point in time. So hopefully he can see others' point of view and communicate accordingly.
When software is written without empathy, maintainability suffers. You get interfaces which defy logic and data structures not representative of any construct in this universe. Consequently, fixes and enhancements are extremely slow. Even if the maintainer is the original developer, he will have difficulty recalling how everything works. Complicated systems cannot easily be stored in one's head; human memory is imperfect, and works by retaining broad patterns. It won't do much to help you remember that your sysFunkFactr variable was actually a counter for potential errors, and it will do do even less to help you recall that you should never attempt to reset sysFunkFactr when systemXFactr is negative and today is Tuesday. These concepts are almost as difficult for the original developer to recall as they are for a new maintainer to learn.
Software architecture is a human-centered activity. "Architecture" here means anything as minor as the names of a variable and as grand as the blueprint of a multi-organisational distributed database. The common element is that humans must understand, evaluate, and maintain these artifacts. So they had better be designed by someone who is cognisant of human cognition.
These ideas are hardly controversial and not barely original. My point, though, is that human-centered design should be an explicit part of mainstream software architecture. Before I discuss what should be done, let's look at what we already have.
Gerard Weinberg wrote about psychology and software as long back as the 1970s. Likewise for Constantine and Yourdon, who argued that diagrams such as their data flow models were all about working with the strengths and weaknesses of human psychology. And Peopleware, focusing more on process issues, was penned by DeMarco and Lister in 1987.
One might have thought the industry would have carried these ideas forward as it matured. It hasn't. Human-centered design and psychology of software are hardly mainstream topics. However, we should not be too pessimistic, because many of today's practices certainly are human-centered. The only problem is we have stumbled upon them by trial-and-error, rather than based the work on explicit application of human-centered design principles.
Here are some contemporary approaches which respect human facilities:
Each of these approaches evolved through a slow process of trial-and-error. Any human-centered rationale given is usually vague, rarely based on human-centered design principles, and almost never validated by empirical evidence. Typically, the closest it gets is a statement like "the language is cool because it lets me work the way I think". Or, "this API is much improved because you don't have to call it a million times just to do the most basic thing". It's nice to know many contributions are intended to support human cognition, but there is a distinct lack of theory and validation.
Software architecture has progressed in this way not by design, but by a process of trial-and-error. Better than nothing, but we have a long way to go. There are several benefits to explicitly considering how software architecture can be more human-centered. I call this approach "Human-Centered Architecture", and it promises these benefits:
This work is licensed under a Creative Commons Attribution 3.0 Unported License.