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?
