How to Avoid the Brittle Code of Technical Debt

by

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.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|