oftware Architect is a great job title. It looks great on business cards. When someone asks you what you do for a living, you can say you’re a Software Architect. It sounds so much better than Software Engineer. The problem arises when this job title leads to the all-too-common behavior of excessive diagrams, rewriting libraries that are available off the shelf, writing wrappers for everything, and instrumentation so excessive that its performance penalties exceed the resource utilization of the actual program’s functions. These behaviors are transforming software development from the practical exercise of delivering what the customer needs into the academic endeavor of building gold-plated monuments to our egos.

Without a doubt, building any piece of software more complex than a few hundred lines of code requires careful planning. Larger projects require a division of work among teams, which in turn requires even more planning to ensure that as the pieces come together in the finished product they will work as expected. The person who does this type of planning is the software architect. He or she decides where one chunk of the application ends and the next one begins, determines the contract between that function and the rest of the system, and then hands it off to developers to write the code.

Unfortunately, the majority of software architects don’t stop there. Fondly thinking of software development as an academic pursuit, they go on to produce an endless array of diagrams and force fit into them as many design patterns—complete with obscure names like “Tombstone”, “Memento”, and “Decorator”—as possible. Architects then feel the need to make their own marks on history by inventing a few more patterns, diagramming them, and bestowing them with new names.

The development teams then try to figure out the endless arrays of diagrams and force fit what the architect demands, which leads them to deliver over-budget, yet underperforming systems to the end users. This isn’t just conjecture; I’ve seen it repeatedly at many organizations.

At one organization, they had a diagram on one wall that was 14 feet long and 4 feet high with tiny print. The architect was so proud of his masterpiece, his brilliance, his grand work. Minor amounts of investigation revealed that none of the team leads had the slightest clue what this massive diagram really meant, but it sure looked cool and impressed the executives when they visited the development area.

Individual developers had received smaller diagrams, filled with blocks and arrows, that told them exactly how to build their piece of the application. While attempting to interpret the diagrams, they had to resort to Googling the obscure patterns referenced and were made to feel incompetent for not knowing what a “Grafter” pattern was. Diagramming is about communicating what you’re building, not about conveying your ability to memorize obscure names for common solutions.

The “Academication” of Software Development
Many in the software industry seem virtually obsessed with trying to make software development as academic as possible. They want to invent new disciplines. The “high priests” of software such as Grady Booch and the Gang of Four (GoF) are all looking to elevate development to a scholarly exercise as opposed to a practical problem-solving endeavor.

Did people make diagrams to describe software before Booch? Sure they did. But since Booch christened diagramming as the Unified Modeling Language (UML), we now have an item to add to our resumes. Did the GoF invent the patterns described in their book? No, software developers have been using them for years. The GoF just gave them names and created yet another meta language for describing what developers do. Meanwhile, countless new programs that could solve all kinds of problems are just waiting to be written and all these scholastic endeavors have produced nothing new in terms of writing innovate code.

Software development is not an academic exercise. It has more in common with the blue-collar “build me a house” ethic than it does with ivory tower research. So let’s quit treating it as if it’s university research. It’s not. Define, design, build, test, deploy—that’s what we do.

Deliver code that does what the end users of the code need or want. No more, no less. From Web sites to database applications to games, it’s all about what your code will do for the end user and not about how you did it. Your end users don’t care if you used a Booch diagram or anointed blocks with arrows and written descriptions to communicate to the development team how you were going to build the software. They care only that the software works the way they expect it to.

By no means am I suggesting that you shouldn’t document your work or plan it out up front. Failing to plan or document is foolish—plain and simple. Turning this planning into an opportunity to show everyone how bright you are is equally foolish and typically much more expensive.

If you’re in charge of the software architecture, whether or not you’ve been bestowed the holy title, keep the focus on designing a system that works. Keep your diagrams simple and understandable. Don’t pay too much attention to whether or not it is a proper Booch diagram or whether it utilizes GoF patterns. Don’t try to micro-design every developer’s piece of the whole, just where it integrates into the whole. Build the system to do what it needs to do, don’t gold plate what the users will never see nor care about.

Just build good software on time and within budget.