When is it time to scrap your old code base and start over?
In last week’s article I mentioned that one of the developers on my team pulled me aside, quite frustrated, and proceeded to tell me how bad the code base is for the product we are delivering. If you want to read the whole backstory then check out last week’s article: Are you really as good a developer as you think you are?
You see, the product we are delivering in the next couple of weeks is built on a code base that has been around for about a decade. We made the decision to use this code base because the existing product met a large number of requirements for this project. However, the developer felt very strongly that we could have built the product from scratch by our deadline and that it would have been as good as or better than the one we had renovated.
So when do we scrap an old code base and start over?
In last week’s article, “Are you really as good a developer as you think you are?” I made the argument that developers, myself included, always feel like they can do a better job than their peers. However, when we make this assessment, we often do not take into consideration the outside pressures and distractions that we deal with daily, all of which impact our productivity and code quality. Outside factors come in many forms like deadlines, project support, meetings, more meetings, and even pointy-headed micromanaging bosses. We evaluate other’s code without any consideration towards how these pressures and distractions may have impacted our peers in the past, and how they will impact us in the future. We have a tendency to underestimate the abilities of our peers and overestimate ours because we rarely factor in these challenges. So, when we consider scrapping an old code base and creating a new one we must recognize that we do not code in a bubble. We must make sure that we take these considerations into account and accurately assess our own abilities before we decide to scrap an old code base and start over.
In my article, “Three things that negatively influence an architect’s design choices” I caution architects and developers from always thinking that the new and shiny is best. In the article I make the argument that developers and architects, myself included, are inclined to look at the new and shiny as the best option, simply because it is newer and shinier than whatever came before it. However, we must always make sure that the solution we recommend is the one that best solves the problem at hand. There are many factors that must be weighed in this decision, but rarely is age one of them. Sometimes the best solution is the new and shiny, but sometimes the new and shiny is just that: new, but not best.
In this week’s article I want to examine that worn out old code base a bit more and discuss how it got that way. Old code bases are like old houses; they were once new and shiny, but as they age they get weatherworn and a bit run down. The owner may not be as particular as she once was when it was new and shiny. She may not have the same attention to detail she once had, but over the years she has made many upgrades and much thought has gone into each. You see, it’s really difficult to foresee what changes will need to be made to a home until you have lived there for a while. The longer you live in a home, the more you begin to see efficiencies that you could have never predicted when you first moved in. Over the years you recognize these efficiencies and modify the original design. Some changes will be small, some large, some well thought-out and some haphazardly. But all are performed with an understanding that took time and experience to acquire.
Code bases are much like that old home you have lived in for years. Many changes were implemented over time, some large, some small, some well thought-out, and some in the middle of the night when we were tired and just wanted to go back to bed. Code bases evolve over time. Sometimes for the better and sometimes not, but every patch, every extension, every enhancement was performed for a reason, and while sometimes it doesn’t look pretty, it’s functional. Old code bases are pressure tested, battle hardened, patched up and aged to perfection to a point where they deliver value to our customers after years of learning and improvements.
New code, on the other hand, is just that: new. It’s code that remains to be tested. It contains bugs that we don’t yet know exist. It contains gaps that our customers will soon point out. New code remains to be tested, like only putting it in a production environment can do. New code can be quite good, but we must always consider that just because it’s new doesn’t mean it’s better; only time and our customers will tell that.
Now don’t get me wrong, I am not arguing that there is no such thing as technical debt. What I am arguing is that old code has been thoroughly tested in ways that the new code simply cannot be. It has faced hard problems and has been enhanced to correct them. Every wrinkle is there for a reason, even if we don’t understand why. Some of the techniques may be a bit dated, but the hard problems have been faced and overcome. There may be some wrinkles and warts, but in the end it really isn’t important how pretty the code is. What is most important is that the code base is providing more value to our customer than it costs to maintain.
So when making the decision to scrap an old code base for a new one, keep in mind the three things I mentioned in this article. Are you accurately assessing your abilities and factoring in that outside challenges may impact your own code quality? Are you choosing the new and shiny because it is the best solution or because it is new and shiny? And always put significant weight on the fact that your old code base is thoroughly tested and providing value to your customers today.
