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.