Technical Debt and Reverse Grind: How to Manage it


It is common practice for a developer to make a quick fix in a software project and to then move onto the next shiny new feature. The development lifecycle is getting increasingly shorter and business goals are beginning to overtake product deadlines rather than the quality of the work being done. 72% of respondents to a DZone survey, said that they often release software before it has adequate testing - this is leading to many projects devolving into mountains of messy code. Two popular devops concepts come into play here: technical debt and reverse grind.

Technical debt, simply put, is the cost of taking shortcuts either through lack of testing, pushing code out to production too soon, or poor documentation. If you let these items go unchecked you can end up in a scenario where you are technically bankrupt. Reverse grind is a concept that first became popular in the gaming scene: it means having to repeat repetitive tasks which need to be done in order to achieve some other goal. Grind is the accumulation of redundant tasks that if they had been done in a scheduled manner over time, wouldn't be a big deal, but when left to do all at once they become extremely tedious.

So what are technical debt and reverse grind costing your organization? They both harm productivity and ultimately cost you money. For each line of code, according to the 2011 CRASH Report (of which there are more recent editions) technical debt costs $3.61. For java developers it gets more expensive with every line of code carrying $5.42 of technical debt.

To put into more tangible terms:

  • a simple iOS app carries about 10,000 lines of code, at $3.61 of technical debt per line of code this app has $36,100 of technical debt.
  • the Mars curiosity rover has about 5 million lines of code, at $3.61 of technical debt per line of code the rover has $18,050,000 of technical debt.

Technical debt can clearly start to add up in cost depending on the scale of a project. So how do you reduce technical debt and reverse grind's impact?

Following a continuous delivery pipeline allows you to be able to track code commits as they go through each stage of testing and staging before deployment - if any issue shows up in the pipeline you can either automatically or manually halt the process. A team can also roll back to the last working release while an issue is being worked out. Visibility for the whole team is what is beneficial about the continuos delivery pipeline. Proper documentation is also important to implement. It is supposed to be common practice but often falls to the wayside. Proper documentation equals to shared product knowledge and increased productivity - it allows for any one working on a section of code to be able to understand what is being done.

However, the most nebulous step that needs to be taken in order to combat technical debt and reverse grind is company culture. If deadlines set by non-technical stakeholders are causing tech debt to accumulate. or if only one developer has the adequate knowledge of a product to resolve issues there is a problem. First you need to be able to communicate with stakeholders about how much time needs to be given in order to create a proper product, and if you only have one developer with full product knowledge they are going to burn out and take all their valuable knowledge with them.

To read the full post visit here.

Filed in: Technical Debt
  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
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
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
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