Be careful before you write off existing software as bad design, you are probably making the same choices yourself!
When you’re an architect, you inevitably find yourself the proud owner of a system or product that you didn’t design but that’s been serving its users for years. This can be a traumatic experience, particularly when you find yourself staring at the results of decisions made under death march pressure, or built with technologies that passed their prime 10 years ago. In those cases its difficult to believe but there is no bad design, only better design.
All developers and architects do their best to make technical decisions based on the following inputs:
If you assume that the developers and architects that came before you tried just as hard as you would to find that perfect middle ground between the three laws of software, then why does the software look so poorly built? The answer is time; time has an affect on all aspects of software design.
- Requirements
- Functional Requirements – It’s been said that software requirements never really change, only your understanding of them does. This is certainly true when that understanding comes over months or even years of use. What the original architects may have thought was a requirement might have only been the passionate request of a single influential person. Or perhaps the requirement came from an email that wasn’t questioned.
- Nonfunctional Requirements – As people have grown more and more accustomed to technology in their lives, their expectations have grown as well. What was once acceptable response times is now frustrating slowness. Don’t be surprised if a design that was once good enough suddenly can’t hold up to modern expectations.
- Technology – These constraints change based on the availability of faster hardware, better networks, and new cloud services. For that software affected by government or industry regulators, the rules change with each new year’s elections.
- Resources
- Number of Resources – You can’t cound on having the same team make up now that the original team had in the past. When a project is new it tends to get resources and funding but when it’s been in the field that dries up and often so do the available resources.
- Skillset of Resources – This can go either way, as junior developers gain experience over time and senior developers move into management and away from technology the skills of the team ebb and flow with the people in them.
- Time
- Fixed Delivery Dates – Death marches do eventually end and release dates pass. What was once the cause of panicked overnight code-fests is now just another day. Except where market competition dictates speed over quality, you find that in the lifespan of enterprise software a single release date is not a big deal. While we may pride ourselves on delivering on-time, a week or even more taken in the name of quality is almost always worth it. Of course that is a perspective that only exists when looking backwards.
- Competition – Some software is actually driven by competitive dates where being first is more important than being better. Those battles are won and lost by the time the software changes hands from one team to another. You’re either first or you’re not and there’s nothing you can do about that now.
When any of these constraints change because of time, another, “better” decision becomes clear. When you’re looking backward at those decisions the constraints inevitably have changed. All you can do is make a better design and hope that the architect who gets your work some time in the future understands the constraints that led to your decisions.