Maintaining Technical Debt and Team Morale in a Large System


In this post from InfoQ, Thomas Bradford explains his experience on working with a monolith java-based system that had improper test coverage and huge technical debt.

When asked what the biggest issue would be when maintaining a large java system, Bradford responded that the prevalence of legacy code riddled with quality issues. This leads to a situation where developers can't modify the system or fix bugs because they might end up simply introducing more due to code complexity and previous development practices (heaps of technical debt).

The technical debt that was present in the legacy code that Bradford was working with was due to the system having been built quickly and as a monolith. This resulted in little to no test coverage (depending on the section of code you were looking at) and the monolithic style of the system created a mess of code with duplicated sections and long methods. A scenario like this makes maintenance extremely difficult and demonstrates an environment where little to no effort had been spent getting the system under control.

One of the biggest motivators to change the way thing were being done and to improve the system came when Bradford heard from various technical leads that often times a product would be rewritten twice, each time with little variance in the result. There was clearly a problem in the code base that kept developers from delivering features efficiently. Bradford said that asides from changing the strategy of working on the java system there also had to be a philosophical change in how developers worked.

Strategically it is impossible to simply ignore technical debt that has built up in a codebase, and that is true in any system. If you allow the technical debt build up to continue you will eventually reach a point where developers won't be able to release any new functionality due to bricked-in code or because developers are so frustrated by the sluggish pace in which they are able to work. Philosophically, Bradford suggested that developers distance themselves from the practices they had become used to over the years (which had caused the slew of technical debt issues in the system) and begin to approach problems with a new mindset.

In order to deal with the insufficient test coverage that had become problematic in the monolithic java system first there had to be an internal effort to get the system under control. Following that effort, unit test coverage was built up but only in the areas that were particularly difficult to work on. But ultimately expanding test coverage in this manner is not the be-all and end-all of problems in a tech debt burdened system. Radical architectural refactoring that takes the monolithic system and start decoupling it has to occur.

Another important aspect of Bradford's interview has to do with sinking team morale that often is the result of a system burdened by technical debt and quick-and-dirty practices. Bradford mentions how developers were afraid to change anything in the code base because in the monolithic system one change could have major unforeseen consequences in another part of the system. By enacting the changes mentioned above and giving developers more autonomy and trust in managing the system they work with daily, morale can only get better.

The idea that work can left until a later moment is a dangerous one, because more often than not it simply goes undone. This is what leads to incurring technical debt. If you find yourself in a situation similar to the one Bradford outlines in the interview, you will have to decide whether a short-term tightening in functionality output is worth avoiding the long-term failure of your organization. The answer to this should be clear: yes it is.

Professional developers have to responsible for the software quality they are building. This means not giving into external pressures to consistently compromising quality because ultimately these compromises will affect everyone in the organization negatively. Its the developers job to make the case for software quality above anything else.

To read the full interview 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
New code

You've already submitted a review for this item