Software architecture does not age gracefully. Software architecture degrades in direct proportion to the number of changes made to the software: bug fixes corrode the layering and new features stress design.
Deciding when the software architecture has degraded sufficiently that you should re-design or re-write a module is a hard decision. On one hand, as the architecture degrades, maintenance and development become more difficult and at the end of that path is a legacy piece of software maintainable only by having an army of brute-force testers for every release, because nobody understands how the software works inside.
On the other hand, users will bitterly complain over the instability and incompatibilities that result from fundamental changes. As a software architect, your only guarantee is that someone will be angry with you no matter which path you choose.
WHAT ABOUT THAT?Total epiphany moment right there.
Written by Margo Seltzer and Keith Bostic (creators of
Berkeley DB) as part of their contribution to
The Architecture of Open Source Applications (CC license, you can
read it on-line, but the paper copy benefits go to Amnesty International).
So, where do I start?!
Software architecture does not age gracefully. Software architecture degrades in direct proportion to the number of changes made to the software: bug fixes corrode the layering and new features stress design.
How many times I've seen that happening. There are several factors adding to that problem:
1) Devs keep understimating how hard fixing bugs really is. We should not ever trust ourselves when we think "
oh, that's a quick fix". If you don't take the time to REALLY understand why the original dev missed the issue, you are quite likely to fix a bug and open a new one. It's always very desirable to have a quick chat with the original dev so you double check you are not missing anything.
2) Devs don't like doing bug fixing, they like implementing new shiny features, so the attitude when bug fixing is "done, get me out of here", which obviously is a recipe for more bugs.
3) It's difficult to keep the consistency over long periods of time, whether when fixing bugs or adding new features. Even with the best of the intentions, maybe you've learnt something since the original implementation, maybe you have different ideas than the original dev... the bigger the team and the longer the project, the tougher is to keep code consistency.
4)
Complexity happens, simplicity you have to strive for.
Deciding when the software architecture has degraded sufficiently that you should re-design or re-write a module is a hard decision. On one hand, as the architecture degrades, maintenance and development become more difficult and at the end of that path is a legacy piece of software maintainable only by having an army of brute-force testers for every release, because nobody understands how the software works inside.
How many times have we asked ourselves "
why has this been coded like this?" Again, if you don't know the answer to that question you are most likely missing important information. And without that information how you solve the problem is likely to add a little bit of a mess. Fast forward 2, 3 or 20 years, put together all those little messes and that's why you have spaghetti code.
On the other hand, users will bitterly complain over the instability and incompatibilities that result from fundamental changes. As a software architect, your only guarantee is that someone will be angry with you no matter which path you choose.
Massive catch 22. When do you make the call? Based on what? I probably should add that to to
the list of what tells appart junior from senior developers.
Same as you should fix bugs during the sprints, you should refactor in your sprints as well. Granted, you can't justify re-writing the whole app on the back of a simple user story, but if you realise the code you need to implement your current user story would greatly benefit from a re-write of this or that other related piece of code, I say do it. Don't accumulate too much technical debt. Don't leave the
window broken for too long.
--
I haven't finished the book yet and I have to say that there are 2 or 3 not-so-good chapters, but
Design Lesson 3 makes it worthwhile.