I seem to always start writing posts on software architecture, and quite rarely do I end up finishing them, much less posting them. I think one reason is that I’m not as much of a loud mouth as some of my contemporaries; as is evident by the lower level of traffic of my blog 🙂 Also, whenever I start writing something about architecture I always sit back, look at it, and say “man, that really is only applicable to a small segment of the software out there.”
I think that this is the core reason why giving unsolicited architecture advice is so hard. It is even why I have said many times before that I believe vendors (including Microsoft) should stray away from giving generic application architecture advice. Advice never works as well for Bob as it did for Frank and vice versa. That just isn’t the nature of advice, two people will always interpret it in many different ways.
So, I was looking at a recent post that I had been writing on about software architecture, and I was having the same thoughts about whether or not it was worth publishing. It got me thinking about whether or not there was any architecture advice that could be given which was truly universal. I thought and thought and came to the realization that the only constant was that we never get our architectures right on the first try.
We can plan upfront as much as we want, but business requirements are a moving target, and feature lists seems to change on a day to day basis. The reminds me of one of my favorite quotes:
“The plan is useless, but planning is essential.”
-Dwight D. Eisenhower
The plans we are creating will almost certainly need to be tossed, and then we need to create new plans. The problem comes when we don’t create new plans and simply try to change things on the fly. This can create architectures which resemble my absolute favorite anti-pattern, the “big ball of mud”. This leads me to my second constant, and that is small annoyances, when left alone, turn into architectural problems. Any time you are writing code and you find yourself having to do something which is repetitive or annoying, fix it. I know you don’t have time, I know you have deadlines, but if you leave it, and perpetuate it, then later on down the road it is going to cause you to miss a deadline.
That slightly annoying feature, copied code, or quirky method, is going to become more deeply embedded in the project. Then, later on down the road, when you get in a situation where you have no choice but to change it, it will be too late. You will be stuck in a quagmire where code has been referenced or copied throughout the system and now it affects much of the system. Sure, some code will never end up like this, but the issue is that you don’t know which ones will and which ones won’t!
To sum it all up, if I had one piece of advice to give anyone building a system, it would be to constantly evaluate the plan, and when needed, change the plan. Constantly evaluate your system and seek out code in your system which could cause trouble in the future. Refactor kitchen sink methods, get rid of unused code, refactor poorly designed classes. You will thank yourself later.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
