Alan Cooper's Has A Dream

In addition to bending my head back during my flight lesson, Alan Cooper always manages to bend my brain back, too. Here's a guy that invented drag-n-drop UI development umpteen years ago and he's been in the business ever since, mostly doing interaction design, but lately trying to tackle the problem of software management. His main thesis is that "web designers are called programmers, programmers are called engineers, engineers are called architects and architects are never called." He justifies this statement by comparing architecture to real-world architecture, which is very different from what the IT industry has co-opted the term mean.

For example, in the world of physical buildings, an architect meets with the clients to understand their needs and listens to their ideas. He then designs a building via a series of increasingly specific sessions with the clients to understand what they need and with engineers to understand what can be done. He uses these interactions to produce blueprints to hand off to the engineer. The engineer decides how to build the building, e.g. what materials to use, what to build or buy, what labor is needed, etc. Before we had mass-produced parts and giant spec books describing every material under the sun, this often required experimentation, which would also feed into the production of a more detailed set of plans to hand off to the construction workers, who do the actual building of the structure. While the structure is built, the engineer and the architect checks in to make sure that things are meeting their requirements and, in fact, it's the engineer's job to sign off when it does. Likewise, there are inspectors that check to make sure things are up to code at certain phases of the project.

In the world of software, we've got inspectors, they're called QA staff. We've got construction workers, they're called programmers. We've got engineers, they're called software engineers, even though we have yet to decide what being a "software engineer" means (often it's just another fancy word for "programmer"). We sometimes have architects, but we tend to rely on the combination of engineering and usability folks, most often skipping the usability and most of the contact with the customer altogether.

Alan's view of the world of software is that, because we don't have this very interactive role that really corresponds to the architect very often, non-technical management really has no idea what's going on in the software construction process. Instead, they have to rely on engineers and programmers to tell them things, when they feel like it, and those guys lie (or plain don't know). Likewise, because there is so little architecture, what comes out the other side is often not what the users want anyway.

In Alan's world, architects fill the role between engineers and customers and non-technical management, designing software that users want and communicating what's going on with management. Likewise, engineers design software to spec that works under stress; programmers build software that doesn't crash; QA checks to make sure that this all happens the way it should.

One of the benefits of Alan's view is that before engineering happens, architects figure out in a detailed and thorough way what needs building, handing complete specs to the engineers. Likewise, before programming happens, engineers run the experiments and make the technology and resource decisions before any code is written, passing off details specs to the programmers. These details specs also flow to the QA folks, which uses them along with their own quality standards to make sure that the software is right before it ships.

If this seems silly, think about an inspector signing off on a house before the foundation is poured, a construction worker pouring the concrete before the plans are done or the engineer deciding on the materials of a building before he knows if it's a house or a mall. Software is certainly more fluid than concrete, but it's not so fluid as we like to believe, as evidenced by the number of failed software projects and the cost overruns associated with them.

We think we're doing architect/engineer/programmer now, but Alan disagrees. What we have is software being hand-made by craftsman from the iron age, but reproduced like appliances from the industrial age. What we need is real engineering for the information age. Alan puts it nicely, "We're standing at the front edge of the information age with really sharp tools from the industrial age."

Of course, what Alan's talking about is the standard waterfall method of software design, which is what I learned in software engineering school. So why don't we do it? Because we don't like drawing up blueprints. We like to make the lights go blinky, blinky on the monitor. Building a shed in your backyard is quicker and easier without an architect or an engineer involved, but is that how you want your house built?

Another benefit of this model of architect/engineer/programmer is that it gives non-technical management much more visibility into and control of the process. You may not think so, but this is good. Right now, the only control they have over the process is the schedule. We say, "That'll take two years," and they say, "You've got four months." Why? Because they've been down the "two year" software process before and gotten burned ~100% of the time, whether the software ships late or it doesn't ship at all. At least if they say "four months," they've only lost 1/6th of the money when/if things go bad. If we want to take the giant hammer of schedule out of their hands, we've got to give them something else so that we have the time we know we need to build quality software that we can be proud of.

I don't know if Alan's right or not, but I sure want him to be. As an architect, I want the tools and the opportunity to design something that the customer will want (I've been down the other road before and it never ends well). As an engineer and as a programmer, I want to build something that will be loved and used when I'm done. Isn't that what we all want?