This post presents an interesting and effective analogy to for those of us that struggle with handling technical debt: spilled juice.
Let's say that once day when you walk into your kitchen there is spilled orange juice on the floor - now you didn't spill that juice but you recognize the problem and clean it up. This is the natural instinct of most people, because if you don't clean up that juice when you see it the problem will only get worse. There are several ways in which the problem can only increase if you leave the juice where it is: you could walk through it and spread the mess through the rest of your home, you could risk having your dog lick up the spill and citrus is poisonous for dogs, or the juice could dry and attract insects that infest your home. These are only a few ways in which your problem can grow over time.
So how is this like technical debt?
If you walk into work one day open up a code file or start working on the database and run into some technical debt (either the code isn't clear, has some inconsistencies, or is lacking test coverage) you have a problem. However, you are more likely to do nothing about this problem than you are in the juice scenario laid out above. This maybe due to your belief that you don't have the authority to fix the problem, or that you don't think you have time to fix the problem because you need to get a new feature into production, or that you don't have the tools to pay back the debt. Ultimately, you can come up with and justify a plethora of excuses to not pay back technical debt in a way that you would not in the spilled juice scenario.
While you may think that technical debt is dissimilar enough to the spilled juice analogy to justify putting it on the back burner, it is just the same in that if left unattended the problem will only get worse. You will end up building new code on debt ridden code and adding onto your debt. You could spread poor quality data through different parts of the application or simply add new tests to new functionality while leaving existing functionality with poor test coverage. All this does is increase the cost of your technical debt in the long run.
So ask yourself: how can you possibly justify any excuse to continue a cycle like this?
What you have to do, is just like when you see spilled juice, is build a habit of cleaning up technical debt when you see it.
To read the full post visit here.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.