Technical debt

A developer team that ap­proaches software de­vel­op­ment or the con­fig­ur­a­tion of IT in­fra­struc­ture in a fast and in­ex­pens­ive manner ‘buys’ these savings for taking on technical debt in return. Technical debt refers to de­lib­er­ate or un­in­ten­ded care­less­ness, errors, and weak points in code. Sub­sequent cor­rec­tions and main­ten­ance reduce pro­ductiv­ity 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 re­fact­or­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­nesses.

The term ‘debt’ also implies interest rates, and technical debt is par­tic­u­larly important for companies to consider from a financial per­spect­ive. Not only does technical debt result in more workload and less pro­ductiv­ity due to sub­sequent main­ten­ance, it also leads to more costs. The more a team of de­velopers neglects to maintain deficient IT in­fra­struc­ture or ap­plic­a­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­sequence 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. Me­tic­u­lously prepared, faultless code is difficult and requires a lot of time to produce. Under some cir­cum­stances, de­velopers, 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 re­fact­or­ing and the code is not regularly optimised, de­vel­op­ment can become bogged down or halted due to meta­phor­ic­al interest.

Marin Fowler, author of Re­fact­or­ing: Improving the Design of Existing Code, fleshed out Cun­ning­ham’s metaphor and sub­divided code debt into four types – visu­al­ised in the technical debt quadrant:

According to Cun­ning­ham and Fowler, technical debt can, therefore, arise de­lib­er­ately or ac­ci­dent­ally. Since tech­no­logy and pro­gram­ming are subject to con­tinu­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 re­fact­or­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­equate quality man­age­ment: Projects are carried out without quality assurance checks, mon­it­or­ing, and test mech­an­isms and ac­cu­mu­late ongoing debt.
   
• Economic pressure: Economic factors and rapid de­vel­op­ment are pri­or­it­ised under pressure from clients or due to com­pet­it­ive pressure, while clean code is neglected.
   
• In­ad­equate qual­i­fic­a­tions: The technical knowledge of the de­vel­op­ment team does not meet the re­quire­ments of elegant, clean code. The con­sequence is code smell or spaghetti code.
   
• In­suf­fi­cient doc­u­ment­a­tion/com­mu­nic­a­tion: The de­vel­op­ment process is carried out without con­tinu­ous doc­u­ment­a­tion of code ex­ten­sions or changes. Code changes are also not recorded or com­mu­nic­ated for sub­sequent pro­gram­mers. The pos­sib­il­it­ies for re­fact­or­ing are limited or un­avail­able.
   
• Postponed re­fact­or­ing: Con­sciously accepted technical debt is not settled in good time, because re­fact­or­ing is neglected or postponed.
   
• Parallel ap­plic­a­tion de­vel­op­ment: Sim­ul­tan­eous de­vel­op­ment steps that are combined and not co­ordin­ated with each other result in the ac­cu­mu­la­tion of code debt.
   
• Too complex code: Code sections are too com­plic­ated 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­plic­a­tion de­vel­op­ment begins before an actual design or specific processes have been defined and agreed.
   
• Code out­sourcing: 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 philo­sophy aims to promote a more pro­duct­ive and flexible ap­plic­a­tion de­vel­op­ment and release.

Instead of being bound to large projects over prolonged periods of time, smaller and more in­de­pend­ent teams handle shorter work phases and quicker releases for smaller projects like ap­plic­a­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­ductiv­ity, there is a greater risk that messy code and technical debt ac­cu­mu­late. Es­pe­cially when agile software de­vel­op­ment is performed without ongoing re­fact­or­ing, debts in­ev­it­ably grow.

The effects of technical debt are much like the con­sequences 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­ductiv­ity, and rising costs.

It is therefore in the interest of clients to arrange extensive and long-term quality man­age­ment and mon­it­or­ing following de­vel­op­ment, in order to avoid the faster and more eco­nom­ic­al 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­pletely elim­in­ated due to new tech­no­lo­gies and changing ap­proaches in software de­vel­op­ment. To release programs and ap­plic­a­tions regularly and quickly, and to ensure teams are not bound to projects for the long term, technical debt is even con­sciously accepted. But there are pre­vent­ive measures for avoiding or reducing the emergence or ac­cu­mu­la­tion of debt:

• In­tro­du­cing stand­ard­ised processes for re­fact­or­ing and quality man­age­ment
• Using con­stantly updated tools for error meas­ure­ment and analysis
• Promoting technical knowledge through con­tinu­ous training, keeping pace with IT de­vel­op­ments, as well as composing teams according to qual­i­fic­a­tions
• Neatly or­gan­ising 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­spons­ib­il­it­ies and functions within teams to prevent du­plic­a­tions, re­dund­an­cies, and coun­ter­pro­duct­ive work steps
• Keeping IT ar­chi­tec­ture up to date through constant mon­it­or­ing, meas­ure­ment, and quality assurance