Technical debt – potential consequences of frugal software development

A developer team that approaches software development or the configuration of IT infrastructure in a fast and inexpensive manner “buys” these savings for taking on technical debt in return. Technical debt refers to deliberate or unintended carelessness, errors, and weak points in code. Subsequent corrections and maintenance reduce productivity and result in additional costly work. What do you need to keep in mind if you wish to avoid technical debt in software development?

In 1992, programmer and co-author of the Manifesto for Agile Software Development, Ward Cunningham, introduced the metaphor of technical debt. Cunningham wanted to make it clear how important refactoring is for software, i.e. regular code corrections. Only this way is it possible to prevent software from taking on more and more “debt” due to growing functional shortcomings and structural weaknesses.

The term “debt” also implies interest rates, and technical debt is particularly important for companies to consider from a financial perspective. Not only does technical debt result in more workload and less productivity due to subsequent maintenance, it also leads to more costs. The more a team of developers neglects to maintain deficient IT infrastructure or applications, the more interest the debts accrue and the more expensive code corrections become.

According to Ward Cunningham, technical debt arises as a consequence of carelessness in code which leads to faster, but imperfect solutions. These development shortcuts are often taken for time or budget reasons. Meticulously prepared, faultless code is difficult and requires a lot of time to produce. Under some circumstances, developers, therefore, opt for messy code to save time and effort. But these savings come with debt.

For Cunningham, this economic aspect of programming is rather normal. If technical debt is not settled with refactoring and the code is not regularly optimized, development can become bogged down or halted due to metaphorical interest.

Marin Fowler, author of Refactoring: Improving the Design of Existing Code, fleshed out Cunningham’s metaphor and subdivided code debt into four types – visualized in the technical debt quadrant:

According to Cunningham and Fowler, technical debt can, therefore, arise deliberately or accidentally. Since technology and programming are subject to continuous overhauls and improvements, code smell, and code erosion can scarcely be avoided. Software also ages and accumulates debt without updates and refactoring. In most cases, however, technical debt is attributable to economic decisions or intentional or unintentional programming errors.

Different types of technical debt usually have similar effects on software development, but their causes may vary considerably.

• Inadequate quality management: Projects are carried out without quality assurance checks, monitoring, and test mechanisms and accumulate ongoing debt.
   
• Economic pressure: Economic factors and rapid development are prioritized under pressure from clients or due to competitive pressure, while clean code is neglected.
   
• Inadequate qualifications: The technical knowledge of the development team does not meet the requirements of elegant, clean code. The consequence is code smell or spaghetti code.
   
• Insufficient documentation/communication: The development process is carried out without continuous documentation of code extensions or changes. Code changes are also not recorded or communicated for subsequent programmers. The possibilities for refactoring are limited or unavailable.
   
• Postponed refactoring: Consciously accepted technical debt is not settled in good time, because refactoring is neglected or postponed.
   
• Parallel application development: Simultaneous development steps that are combined and not coordinated with each other result in the accumulation of code debt.
   
• Too complex code: Code sections are too complicated or make little sense. Small changes can result in more errors and multiple debt. In the worst cases, spaghetti code can also arise here.
   
• Unstructured development processes: Application development begins before an actual design or specific processes have been defined and agreed.
   
• Code outsourcing: Development steps are outsourced, leading to code errors when the sections are later combined. These errors are either tolerated or missed by team management.
   
• Quick changes at short notice: Quick changes to the code are not tested due to time pressure.

Ward Cunningham not only defined the metaphor of technical debt, but was also co-author and a first signatory of the Manifesto for Agile Software Development. This software development philosophy aims to promote a more productive and flexible application development and release.

Instead of being bound to large projects over prolonged periods of time, smaller and more independent teams handle shorter work phases and quicker releases for smaller projects like applications, program sections, and updates.

Agile software development results in teams writing and changing small sections of code and completing work steps more quickly. By focusing on speed and productivity, there is a greater risk that messy code and technical debt accumulate. Especially when agile software development is performed without ongoing refactoring, debts inevitably grow.

The effects of technical debt are much like the consequences of loans in finance. If the debts aren’t paid down regularly and on time, interest accrues, which manifests itself in slower development, falling productivity, and rising costs.

It is therefore in the interest of clients to arrange extensive and long-term quality management and monitoring following development, in order to avoid the faster and more economical completion and release of products from incurring costly corrections or development gridlock at a later date.

Technical debt can’t be completely eliminated due to new technologies and changing approaches in software development. To release programs and applications regularly and quickly, and to ensure teams are not bound to projects for the long term, technical debt is even consciously accepted. But there are preventive measures for avoiding or reducing the emergence or accumulation of debt:

• Introducing standardized processes for refactoring and quality management
• Using constantly updated tools for error measurement and analysis
• Promoting technical knowledge through continuous training, keeping pace with IT developments, as well as composing teams according to qualifications
• Neatly organizing code with the use of subdivisions into classes and clear methods, and writing code in a manner that is understandable for new or external programmers
• Setting clear responsibilities and functions within teams to prevent duplications, redundancies, and counterproductive work steps
• Keeping IT architecture up to date through constant monitoring, measurement, and quality assurance