How to Minimize Technical Debt and Reverse Grind
Fight technical debt and reverse grind before they decrease long-term productivity and ultimately cost your organization money.
Join the DZone community and get the full member experience.Join For Free
We see it everyday – developers make quick fixes to an application and then they’re on to something new. The development lifecycle is getting increasingly shorter and business goals can often determine product launch deadlines over the quality of the application. In fact, DZone surveyed developers and found that 72% of respondents have had to release software with less testing than they thought was necessary. Tough deadlines and quick patches can quickly become mountains of disorganized code.
Two DevOps concepts come into play here, technical debt and reverse grind—both of which can be avoided with the proper tools and mindsets.
What is Technical Debt?
Technical debt is the cost of taking shortcuts and making mistakes in your code. You could have gotten here through lack of testing, pushing code into production too soon, or not documenting every patch and issue.
Many software development departments go through this, and if the debt stacks high enough, it may become impossible to get back in the black.
What is Reverse Grind?
If you’re a gamer, you may be familiar with the term “grind.” Grinding means you have to complete repetitive tasks, and in the gaming sense, normally to complete a level or move on in a game.
A similar concept in the coding world, reverse grind is an accumulation of repetitive tasks you’ve postponed, and now you have to backtrack and complete what is now a large project. Had you stuck to the routine of doing these tasks in the moment, they would not be difficult to complete since you'd be the correct mindset. By letting them build up you have to be in a totally different state of mind, and repeated repetitive work like this can become tedious quickly.
What Technical Debt and Reverse Grind Are Costing You
It’s obvious why technical debt and reverse grinding are major problems for any developer team – they’re harming productivity and ultimately costing money. We’ve already revealed that a question can end up costing $25,000 to a team – so how much is technical debt and reverse grind costing you?
In the 2011 CRASH Report, it was determined that each line of code carries $3.61 of technical debt.
And for Java developers – it gets worse. Java applications actually had higher technical debt, at $5.42 per line of code.
In 2012, Jim Bird investigated where technical debt is coming from in your code. So let’s put that into scope (assuming that the following instances have no proper process set up to minimize technical debt):
Simple iOS app game:
10,000 lines of code x $3.61 = $36,100 of technical debt
The Mars Curiosity Rover has about 5 millions lines of code, most of which are written in C.
5M lines of code x $3.61 = $18,050,000 of technical debt
Let’s look at the Android OS, which is comprised of about 12 million lines of code including 3 million lines of XML, 2.8 million lines of C, 2.1 million lines of Java, and 1.75 million lines of C++.
[(3M lines of code + 2.8M lines of code + 1.75M lines of code) x $3.61] + (2.1M lines of code x $5.42) = $38,637,500 of technical debt
The numbers speak for themselves, technical debt can really add up without the correct tools and techniques to mitigate it. So how can you minimize your technical debt and the cost of reverse grind?
How to Avoid and Minimize Reverse Grind and Technical Debt
1. Committing changes to source control and through Continuous Delivery pipelines
One way to minimize reverse grind and technical debt is by committing changes to source control and following a Continuous Delivery pipeline. Following a CD pipeline will allow you to track your code commits as they move through testing and staging before they are deployed. If there are any significant issues found (and the change hasn’t been deployed to production), the pipeline can either be halted manually or automatically, or the team can rollback Production to the last working release (in the case that the change has already been deployed to Production). This will keep your random code updates and patches well-documented and visible to the whole team.
2. Proper documentation in an established process
It's supposedly common practice to document all patches, fixes, and changes, but too often this step is skipped in the interest of time. While it takes more time upfront, it will save you and your team time in the long run. And if you use a knowledge management and collaboration tool, like AnswerHub, you can bring visibility and a knowledge base into your documentation process. Along with sharing your knowledge instead of hoarding your product knowledge, you can show off your expertise in your organization. You can't assume that everyone can read your code and know exactly how it's supposed to work.
3. Make it part of your company culture
A lot of times technical debt is the outcome of an organization’s culture – and the whole company needs to be involved. That means executives and managers need to create a system and an understanding for proper documentation – and then they need to follow that process, too. It's crucial that if deadlines start looming not to give in to the pressure to commit quick fixes, or the work to establish this culture can quickly come undone.
Team leads can also discourage technical debt by not putting the smartest developer on every issue. While the problem may be solved in less time at the first go, one developer can’t handle the workload of fixing every bug. And if they left the company due to the burnout of being overloaded for so long? That vital knowledge would go right with them.
So before you make your next patch or do a small project, take into account the how you can minimize technical debt in your organization. Reducing technical debt in your code will make your team more efficient in long term and keep your application quality standards high.
Published at DZone with permission of Chelsea Bosworth. See the original article here.
Opinions expressed by DZone contributors are their own.