When working on a legacy codebase, you might start to wonder how anyone could have ever let it get to be such a mess. You may think that the mess you have encountered is due to incompetent developers but that is not usually the whole story behind messy code. What you are most likely dealing with is code riddled with technical debt.
Technical debt is code that does the job it is meant to do but is not built in a way that allows easy maintenance or the possibility of being built upon stably. Taking on technical debt in an unfettered fashion means that your project's code is corrupted. So given this scenario, your next thought will probably be how you can get the codebase under control in order to bring it to a new level of maturity.
Technical debt is typically at play in any software project, and if it isn't this means that you are probably working at a rate that is too slow for you to keep up with your competitors. Your competition is most likely using technical debt to release features to market sooner than you, and the result is that you will be lagging behind them in what you offer users and will start to loose business. What this means is that technical debt is a necessity, but you have to keep it in check or else your code will become unmanageable.
In order to pay off your debt to keep it from reaching unmanageable levels you have to refactor. Refactoring is the process of swapping out pieces of code with another piece of code that does the same function but is more easily manageable. Due to the fact that there is always new functionality that stakeholders want to be implemented in a given software project, where the deadline was always last week and developers are made to feel incompetent for not having completed their task two weeks ago, you will mostly likely have to explain why you need the time to rebuild technical debt ridden code.
This is a critical juncture in any project (and the reason for why the technical debt metaphor is so useful in the first place, as it offers a non-technical explanation of the pains developers face) because if you don't succeed at convincing stakeholders to allow you the time to refactor, technical debt will only continue to amass. Ultimately, you and any non-technical stakeholder want the same thing out of a software project: a profitable product that you can expand upon without the fear of sudden collapse.
So for the benefit of you and your project go through the following steps when speaking about refactoring to a non-technical stakeholder:
- Explain what technical debt means and how it makes development slow down to half speed when it goes unmanaged. The costs of technical debt reveal themselves in time spent fixing bugs and the new insufficiency of time to add new features that arises from having to spend time fixing these bugs.
Then you must explain:
- The next step to dealing with technical debt is refactoring with a clear set of short term goals in mind. This includes a trade off like this: either you release a new feature in a week, or you can refactor for a week and add the new feature in a day due to increased ease of use in the codebase.
- Refactoring is often more expensive in the short term but cheaper in the long term.
However, while refactoring is a useful tool, beware the tendency to go for a full rewrite.
Here are the main risks of a rewrite:
- It is new code that has never run in production and is therefore likely to explode in first production use.
- The migration of data, exporting and importing data, from the old data system while keeping up with live data coming in is just asking for trouble.
- While rewriting code you will create bugs, recreate old bugs, and these problems will begin to appear in areas of the code that were not problematic to begin with.
A rewrite will ultimately waste time and not add any value to your business. The new code will need to rebuild old features, all the while new features are being continually added to the old project causing more work needed to be done than necessary. So don't start over, all you need to do is simply improve what you already have.
Bit by bit by swapping out old technical debt ridden code for new well written code will get you to the point where you won't recognize any old code left over in the project. This means that you need to break down code dependencies so you can move around code, and once you have self contained code you can test it maintain standards.
What it all comes down to is isolating and replacing tech debt heavy code.
To read the full post visit here.