email article printer friendly more resources

The Software Practitioner Triad
by Alan Cooper

Enterprise Application Lifecycle Management 2003

Alan Cooper
Agree? Disagree? Let us know by e-mailing us at vsmedit@fawcette.com.    The opinions expressed in this editorial are those of the author and not necessarily the opinions of VSM.

Today, Web designers are called programmers, programmers are called engineers, engineers are called architects, and architects never get called. Not only are our titles mixed up, but our community of software practitioners is also deeply confused about the roles we play. The confusion is even worse in the minds of the businesspeople who hire us and set our budgets and schedules.

In my last column, I showed that programming—constructing release code—isn't the same as engineering (see Additional Resources). Production programming is as demanding, difficult, and creative as engineering, but its primary goal is producing a shippable product, not solving its technical problems. Shippable programs are mostly protective code that rarely—if ever—executes. Hundreds of thousands of lines of
code are dedicated to supporting obscure edge cases, platform idiosyncrasies, and error conditions. The code must then be tested vigorously and thoroughly. These demands multiply many times the cost in both time and money of any backtracking or last-minute changes to release code. As Frank Lloyd Wright said, "You can use an eraser on the drafting table or a sledgehammer on the construction site."

On the other hand, technical problem solving demands experimentation, which is naturally repetitive and empirical. This means that the tasks repeat, and failure is as educational as success. But failure and repetition are antithetical to production's nature. Conversely, for the engineer's iteration and experimentation to be fast, accurate, and cost-effective, it can't be fettered with the demands of producing release code.

Clearly—for the sake of the schedule, the budget, and the customer—programmers should never be tasked with engineering duties, and engineers should never be directly responsible for programming release code. But even if a shop establishes these two roles correctly, a key piece of the complete solution is still lacking.

The panoply of software construction includes three vital roles: the programmer, the engineer, and the architect. The architect is responsible for determining who the user is, what he or she is trying to accomplish, and what behavior the software must exhibit to satisfy these human goals. The engineer's responsibilities are comparable but focused on technology. A good engineer can and should ignore human issues, confident that the architect will cover the human side.

The bulk of the role confusion arises from the simple fact that few software projects are architected. Instead, the programmers and the engineers try—with limited success—to fill in the gap. What's more, the title itself is often confused with the obsolete and ill-named "software architecture," which is advanced software engineering done close to the metal.