One of the greatest issues of dealing with technical debt is the brittle code that comes along with it. Brittle code is any code in the codebase that is resistant to change. In this post we outline a few ways in which you can deal with this code that is painful to change.
Persistently updating your dependencies and frameworks is a good way to keep your code flexible to change. This may seem obvious to most developers now, but was not the case over 10 years ago. And although it seems obvious now, just because developers know they should be updating their dependencies and frameworks doesn't mean they are.
The more painful it is to update the more you should be updating your dependencies and frameworks. The more you update the less painful it becomes and then it will become a non-issue. Asides from making working on code less difficult, updating is a necessity for fixing security vulnerabilities in your codebase. The easier it is to update your codebase, the quicker and more effectively you can ship security vulnerability fixes. Another incentive for updating frequently, is that in most teams the process of updating is labeled as technical debt. Although technical debt is a much easier topic to broach with non-technical stakeholders now than it was 10 years ago, it is still a difficult discussion to have. If you are constantly updating and it is not a pain point anymore, you no longer have to have the technical debt conversation with stakeholders.
Quick and effective unit tests are one of the surest ways to ensure the longevity of your code. The reason why it is integral to the success of your code that you ensure that your unit tests are quick is due to the nature of the cycle of adding new features to your codebase:
- First you must write a failing test.
- Then you write your code.
- And, get it to green.
If you're going through this process the correct way then unit tests should be completed throughout the whole process. And these tests shouldn't make you have to wait 1o-20 minutes while they run after you change anything in the code base. If you have to wait around for tests to run in the coding process it will become tedious experience.
This isn't the only reason why you need a quick test suite.
At one point the size of your application will become so large that you will need to start looking at how to break your code base apart in order to work on smaller segments of code at a time. This means finding seams within the application along which to break the monolith. There is no one way to do this and requires quite a bit of experimentation and moving around of code; therefore, having a quick test suite makes validating your work along the way much easier and makes this process several times easier.
Talking about technical debt does not guarantee that any one is going to actually pay it back. In fact, sometimes having technical debt in the backlog makes it more likely that it will never get paid back as it will keep getting pushed to the back burner. The 'urgent' list will end up only getting longer.
If you aren't dealing with your technical debt in your legacy code the chances are that you're dealing with brittle code. Going through the processes above will enable you to deal with this type of code, but you also have to remind stakeholders that paying back technical debt is integral to process as well.
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.