5 Favorite Excuses to Avoid Fixing Your Architecture

Do you remember your last quarrel over whether the current architecture of your software is a good one? Were you defending or attacking?

I’m sure some parts of that discussion weren’t completely rational. Here’s a list of some of my favorite irrational arguments against fixing a broken architecture. Maybe the list helps you recognize them as irrational the next time you hear them or use them yourself.

1. It’ll be fine after these fixes

This one is popular among people who have never really written a lot of code, at least not of the high quality kind. They view software quality as something than can be added later. They think quality is something which can be poured in later, in controlled doses, carefully avoiding adding too much to avoid spending too much time on quality which is above the market expectation.

High software quality has to be built in right from the start. You can’t pour it in afterwards. If the design is poor, no amount of bug fixing will get you to rock solid. If you keep fixing it long enough, you might get to “works most of the time”, but you will never reach rock solid.

2. There is no problem

Flat-out denying that there is any problem is a powerful trick. Deny all evidence. If there is evidence, place the blame on third parties, the operating system, the users, whatever. If you have to, shoot the messenger.

The tendency to employ this technique seems to be stronger in people who have spent considerable amounts of time designing and creating the broken architecture. You probably define yourself through the work you have done, at least to some extent. What was the last thing you created which you are proud of? How hard would it be to admit that your creation is, in fact, a load of crap? I bet it would be easier for you to find fault somewhere else, or simply deny that there is anything wrong in the first place.

3. Developers always want to rewrite everything anyway

The power of this technique lies in the fact that there is a grain of truth in it. Many developers have this built-in tendency to build new stuff instead of patching up the old stuff. For me, I think it has something to do with how I was introduced to programming. I fell in love with creating new impressive things, and that’s what I want to do again and again.

However, that grain of truth is not a logical argument against fixing your architecture. If you know that the smelly guy down the hall always eats at Burger King and never at McDonalds, you still have no information about which is the better choice for lunch. All you know is that the smelly guy likes his whoppers.

4. It was built by our best engineers

The architecture was designed by your very best engineers, so it cannot possibly be a bad architecture, right? Besides, those engineers are too important to risk making them mad. If we can’t trust our best engineers, who can we trust?

Smart people do stupid things all the time. It’s often impossible to know beforehand how something turns out to work in real life. The smart thing to do is to adjust, refactor, redesign, and rewrite as necessary. It’s not very smart to keep going with the first thing that kinda worked.

5. This architecture will give us benefits in the future

This technique works best if you are vague. Things such as scalability and flexibility sound good, as do promises about how the architecture can be leveraged in the future to rapidly build new and innovative applications. Being very specific and concrete will probably reveal that the architecture is not, in fact, superior to the alternatives.

So, that was my list of favorite techniques to bury your head in the sand. When was the last time you used them yourself? What would you add to the list?