5 Architecture Mistakes to Avoid

“Success does not consist in never making mistakes but in never making the same one a second time.” --George Bernard Shaw

“Insanity: doing the same thing over and over again and expecting different results.” --Albert Einstein

In a previous article I referenced what I consider to be the two biggest sins a software architect can make. Following is a list of what I consider the biggest preventable mistakes an architect can make. These mistakes can tank a project or cause major grief after deployment and are all preventable if you keep them in mind.

1. Missing the obvious

It’s embarrassing when you've realized that you've designed an online payment processor that can’t cleanly handle the addition of a new payment vendor or a new method of payment. This is Software Architecture 101. Assume that at some point in time there will be a need to use a new vendor because they offer a type of payment that your current vendor does not.

Whether it’s a hard-coded value, a data type used outside of a reasonable context, or a missed design pattern, this mistake is a landmine. And no one wants Amnesty International protesting your code base.

2. Accounting for the unreasonable

Over-architecting is as bad as under-architecting. Don’t create a multiple endpoint web service that acts as a front end to a Windows service unless you’re certain that a piece of functionality needs to be that accessible. Don’t react to “This might change”. React to “This is likely to change.”

3. Being overly clever

We've all done it at one point in time or another. We all want to show how clever we are, or how smart we are, or how innovative we are. We've all, at one time or another, written a section of code that makes others go “Wait... what?” The urge to do this does not make you a bad developer. It makes you normal. Well, normal as the term relates to software developers.

That being said, elegant code is code that solves a problem in a manner that seems effortless. It is not defining every method of a class as a closure so that the entire functionality of the class can be redefined at runtime. If your code is so abstract that you need a Philosophy degree to understand it, you need to rethink. Prefer simplicity in your designs. The next guy will thank you for it.

4. Not understanding the platform

Sure- software architecture concepts apply across platforms. It doesn't matter what you use, you break up your application into usable modules (whatever you call them) that do one thing. The Strategy Pattern is useful in any OOP environment, and the underlying concept is important for Functional Programming.

That being said, if you don’t understand the tools that your development platform offers, you can only choose the correct tools by luck. And luck is a terrible thing to rely on.  Rails is not the same as .Net is not the same as Java is not the same as ColdFusion. And while approaching design on a platform from the point of view gained from another platform can yield some interesting insights, if you don’t understand your platform you almost can’t help but miss something. Building a webservice in .Net? Better understand WCF. Building anything in Ruby on Rails? Get used to Gems and understand what they offer. Get used to the Active Record Pattern. Doesn't matter if you don’t like it (I don’t), you can’t understand how to account for its weaknesses, and whether or not it’s worth bothering to do so, if you don’t understand how it works in the first place.

5. Being single-focused

This isn't exactly the “If all you have is a hammer, all problems look like a nail” adage that is so common in software development. This is the acknowledgement that developers tend to see projects through a particular lens, regardless of their skills or experience. I tend to write class libraries that serve as an API for whatever front end application may need to consume them. In general, this has served as a solid solution and has become something of a “Go-To” approach for me. Until, on my current project, the dev lead ask me “Why aren't we using SSIS?” He was absolutely right, too. SSIS was the right solution. Don’t fall in love with a particular tool. Be flexible enough to choose the right tool.

Bonus Mistake

The assumption that being an architect makes you right and forgetting that it makes you accountable. Okay- that’s a bonus mistake two-fer.

*Always* listen to what the team developers have to say, regardless of whether or not you agree with them. In fact, especially if you don’t agree with them. Not listening to skilled professionals makes them mad, which will lead to all sorts of problems. They’re the ones actually using the software design you've created, and when the rubber hits the road it’s not uncommon to find some bumps. On the other hand, if the feedback you get is consistently taking a problematic path, you know you need to step back and talk to the dev team so you can come to some basic understandings of how you see things and how they see things.

That being said, at least where I work, architecture is not a democracy. We don’t vote on it and if I create something that doesn't work “But the dev team liked it better” doesn't cut it. I’m responsible for the design. That means listening. That means thinking. That also means being able to make a decision. And at some point making a decision means being able to say “Thank you for your input. I've taken your feedback into consideration and this is the direction we’re taking.”

These mistakes can all turn an application or a development project ugly. They can cause maintenance issues, extensibility issues, or project issues. They can manifest themselves quickly or lie in wait until another factor brings them to light. But they are all preventable and mark the difference between the architect that helps create an elegant and useful solution, and the architect that development teams have to put up with and work around in order to release something workable.