Technical debt

A developer team that ap­proach­es software de­vel­op­ment or the con­fig­u­ra­tion of IT in­fra­struc­ture in a fast and in­ex­pen­sive manner “buys” these savings for taking on technical debt in return. Technical debt refers to de­lib­er­ate or un­in­tend­ed care­less­ness, errors, and weak points in code. Sub­se­quent cor­rec­tions and main­te­nance reduce pro­duc­tiv­i­ty and result in ad­di­tion­al costly work. What do you need to keep in mind if you wish to avoid technical debt in software de­vel­op­ment?

In 1992, pro­gram­mer and co-author of the Manifesto for Agile Software De­vel­op­ment, Ward Cun­ning­ham, in­tro­duced the metaphor of technical debt. Cun­ning­ham wanted to make it clear how important refac­tor­ing is for software, i.e. regular code cor­rec­tions. Only this way is it possible to prevent software from taking on more and more “debt” due to growing func­tion­al short­com­ings and struc­tur­al weak­ness­es.

The term “debt” also implies interest rates, and technical debt is par­tic­u­lar­ly important for companies to consider from a financial per­spec­tive. Not only does technical debt result in more workload and less pro­duc­tiv­i­ty due to sub­se­quent main­te­nance, it also leads to more costs. The more a team of de­vel­op­ers neglects to maintain deficient IT in­fra­struc­ture or ap­pli­ca­tions, the more interest the debts accrue and the more expensive code cor­rec­tions become.

According to Ward Cun­ning­ham, technical debt arises as a con­se­quence of care­less­ness in code which leads to faster, but imperfect solutions. These de­vel­op­ment shortcuts are often taken for time or budget reasons. Metic­u­lous­ly prepared, faultless code is difficult and requires a lot of time to produce. Under some cir­cum­stances, de­vel­op­ers, therefore, opt for messy code to save time and effort. But these savings come with debt.

For Cun­ning­ham, this economic aspect of pro­gram­ming is rather normal. If technical debt is not settled with refac­tor­ing and the code is not regularly optimized, de­vel­op­ment can become bogged down or halted due to metaphor­i­cal interest.

Marin Fowler, author of Refac­tor­ing: Improving the Design of Existing Code, fleshed out Cun­ning­ham’s metaphor and sub­di­vid­ed code debt into four types – vi­su­al­ized in the technical debt quadrant:

According to Cun­ning­ham and Fowler, technical debt can, therefore, arise de­lib­er­ate­ly or ac­ci­den­tal­ly. Since tech­nol­o­gy and pro­gram­ming are subject to con­tin­u­ous overhauls and im­prove­ments, code smell, and code erosion can scarcely be avoided. Software also ages and ac­cu­mu­lates debt without updates and refac­tor­ing. In most cases, however, technical debt is at­trib­ut­able to economic decisions or in­ten­tion­al or un­in­ten­tion­al pro­gram­ming errors.

Different types of technical debt usually have similar effects on software de­vel­op­ment, but their causes may vary con­sid­er­ably.

• In­ad­e­quate quality man­age­ment: Projects are carried out without quality assurance checks, mon­i­tor­ing, and test mech­a­nisms and ac­cu­mu­late ongoing debt.
   
• Economic pressure: Economic factors and rapid de­vel­op­ment are pri­or­i­tized under pressure from clients or due to com­pet­i­tive pressure, while clean code is neglected.
   
• In­ad­e­quate qual­i­fi­ca­tions: The technical knowledge of the de­vel­op­ment team does not meet the re­quire­ments of elegant, clean code. The con­se­quence is code smell or spaghetti code.
   
• In­suf­fi­cient doc­u­men­ta­tion/com­mu­ni­ca­tion: The de­vel­op­ment process is carried out without con­tin­u­ous doc­u­men­ta­tion of code ex­ten­sions or changes. Code changes are also not recorded or com­mu­ni­cat­ed for sub­se­quent pro­gram­mers. The pos­si­bil­i­ties for refac­tor­ing are limited or un­avail­able.
   
• Postponed refac­tor­ing: Con­scious­ly accepted technical debt is not settled in good time, because refac­tor­ing is neglected or postponed.
   
• Parallel ap­pli­ca­tion de­vel­op­ment: Si­mul­ta­ne­ous de­vel­op­ment steps that are combined and not co­or­di­nat­ed with each other result in the ac­cu­mu­la­tion of code debt.
   
• Too complex code: Code sections are too com­pli­cat­ed or make little sense. Small changes can result in more errors and multiple debt. In the worst cases, spaghetti code can also arise here.
   
• Un­struc­tured de­vel­op­ment processes: Ap­pli­ca­tion de­vel­op­ment begins before an actual design or specific processes have been defined and agreed.
   
• Code out­sourc­ing: De­vel­op­ment steps are out­sourced, leading to code errors when the sections are later combined. These errors are either tolerated or missed by team man­age­ment.
   
• Quick changes at short notice: Quick changes to the code are not tested due to time pressure.

Ward Cun­ning­ham not only defined the metaphor of technical debt, but was also co-author and a first signatory of the Manifesto for Agile Software De­vel­op­ment. This software de­vel­op­ment phi­los­o­phy aims to promote a more pro­duc­tive and flexible ap­pli­ca­tion de­vel­op­ment and release.

Instead of being bound to large projects over prolonged periods of time, smaller and more in­de­pen­dent teams handle shorter work phases and quicker releases for smaller projects like ap­pli­ca­tions, program sections, and updates.

Agile software de­vel­op­ment results in teams writing and changing small sections of code and com­plet­ing work steps more quickly. By focusing on speed and pro­duc­tiv­i­ty, there is a greater risk that messy code and technical debt ac­cu­mu­late. Es­pe­cial­ly when agile software de­vel­op­ment is performed without ongoing refac­tor­ing, debts in­evitably grow.

The effects of technical debt are much like the con­se­quences of loans in finance. If the debts aren’t paid down regularly and on time, interest accrues, which manifests itself in slower de­vel­op­ment, falling pro­duc­tiv­i­ty, and rising costs.

It is therefore in the interest of clients to arrange extensive and long-term quality man­age­ment and mon­i­tor­ing following de­vel­op­ment, in order to avoid the faster and more eco­nom­i­cal com­ple­tion and release of products from incurring costly cor­rec­tions or de­vel­op­ment gridlock at a later date.

Technical debt can’t be com­plete­ly elim­i­nat­ed due to new tech­nolo­gies and changing ap­proach­es in software de­vel­op­ment. To release programs and ap­pli­ca­tions regularly and quickly, and to ensure teams are not bound to projects for the long term, technical debt is even con­scious­ly accepted. But there are pre­ven­tive measures for avoiding or reducing the emergence or ac­cu­mu­la­tion of debt:

• In­tro­duc­ing stan­dard­ized processes for refac­tor­ing and quality man­age­ment
• Using con­stant­ly updated tools for error mea­sure­ment and analysis
• Promoting technical knowledge through con­tin­u­ous training, keeping pace with IT de­vel­op­ments, as well as composing teams according to qual­i­fi­ca­tions
• Neatly or­ga­niz­ing code with the use of sub­di­vi­sions into classes and clear methods, and writing code in a manner that is un­der­stand­able for new or external pro­gram­mers
• Setting clear re­spon­si­bil­i­ties and functions within teams to prevent du­pli­ca­tions, re­dun­dan­cies, and coun­ter­pro­duc­tive work steps
• Keeping IT ar­chi­tec­ture up to date through constant mon­i­tor­ing, mea­sure­ment, and quality assurance