39   Architects Must Write Code

“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.”

The industry is full of people with the title Software 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 jargon, 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 effective 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 ​Let Design Guide, Not Dictate​): 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 understanding 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 decisions may be made from miles away, but tactical decisions—decisions that determine victory or defeat—require significant understanding of what’s on the ground.^[37]

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?”^[38] 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 reversibility is a key component of the pragmatic approach (see the sidebar here).

Encourage your programmers to design. A lead programmer may take the role of an architect—and may indeed wear different hats. This person is immersed in design issues, but not at the expense of giving up coding. If developers are reluctant to take on these design responsibilities, pair them with someone who can design well. A programmer who refuses to design is a person who refuses to think.

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.