“Fred, our expert architect, will deliver a design for you to code.
He’s very experienced and very expensive, so don’t waste his time with silly questions or implementation problems.”
You can’t code in PowerPoint
The industry is full of people with the title Soft- ware Architect. It’s a title your authors don’t like much, and here’s why: an architect is a person who designs and guides, but many of the people with Architect on their business cards don’t deserve the title.
An architect is not a person who just draws pretty pictures, speaks jar- gon, and uses lots of patterns—such designers are often ineffective.
They typically come in during the beginning of a project, draw all kinds of diagrams, and leave before any serious implementation takes place.
There are many “PowerPoint architects” out there, and they aren’t effec- tive because of lack of feedback.
A design is specific to the problem at hand, and your understanding of the problem changes as you implement that design. It’s hard to come up with an effective detailed design up front (see Practice11,Let Design Guide, Not Dictate, on page48): there isn’t enough context, and there’s little or no feedback. Design evolves over time; you can’t design a new feature, or an enhancement, by ignoring the realities of the application (its implementation).
As a designer, you can’t be even marginally effective without under- standing the nitty-gritty details of the system. You don’t get this kind of understanding working solely with high-level diagrams.
It’s like trying to conduct a battle from miles away by looking only at the map—once the battle begins, planning is not sufficient. Strategic deci- sions may be made from miles away, but tactical decisions—decisions that determine victory or defeat—require significant understanding of what’s on the ground.1
1In World War I, the Battle of the Somme was intended to be a decisive breakthrough.
Instead, it became the greatest military folly of the twentieth century, mostly because of a loss of communication and the way the commanders insisted on following the plan even when facing a very different reality. Seehttp://www.worldwar1.com/sfsomme.htm.
ARCHITECTSMUSTWRITECODE 153
Reversibility
The Pragmatic Programmer[HT00] points outThere Are No Final Decisions. No decision you make should be cast in stone.
Instead, consider each major decision about as permanent as a sandcastle at the beach and explicitly plan ahead for change.
Designer of a new system by Donald E. Knuth
The designer of a new kind of system must participate fully in the implementation.
As Knuth says, a good designer is someone who can roll up his sleeves and get his hands dirty, coding without hesitation. A true architect would protest mightily if told they couldn’t be involved in the code.
A Tamil proverb suggests that “A picture of a vegetable doesn’t make good curry.” Similarly, a paper design will not make a good application.
Design should be prototyped, tested, and validated as well—it has to evolve. It’s the responsibility of the designer, or the architect, to realize a design that actually works.
Martin Fowler, in his article entitled “Who Needs an Architect?”2 says that the role of a real architect “...is to mentor the development team, to raise their level so that they can take on more complex issues.” He goes on to say, “I think that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs.” Fostering reversibilityis a key component of the pragmatic approach (see the sidebar on this page).
Encourage your programmers to design. A lead programmer may take the role of an architect—and may indeed wear different hats. This per- son is immersed in design issues, but not at the expense of giving up coding. If developers are reluctant to take on these design responsibili- ties, pair them with someone who can design well. A programmer who refuses to design is a person who refuses to think.
2http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Report erratum
ARCHITECTSMUSTWRITECODE 154
Good design evolves from active programmers. Real insight comes from active coding. Don’t use architects who don’t code—they can’t design without knowing the realities of your system.
What It Feels Like
Architecture, design, coding, and testing feel like different facets of the same activity—development. They shouldn’t feel like separate activities.
Keeping Your Balance
• If you have one chief architect, he or she may not have enough time to be a full-fledged coder as well. Keep them involved but not on the critical path on the largest piece of code.
• Don’t let anyone design in isolation, especially yourself.
PRACTICECOLLECTIVEOWNERSHIP 155