Many people asked about Technical Debt and its implication to the managers of software development companies. I summarize the relevant information (most of them are public information from the Internet) below in Q&A format:

Q:What is Technical Debt (a high level view) ?

A:

When you want to add a functionality to your system, there are two ways to do it:

1) Quickly  do it but messy - you are sure that it will make further changes harder in the future.

2) Do it properly with good design. It will results in a cleaner design, but will take longer to put in place.

Technical Debt is a metaphor developed by Ward Cunningham in 1992 to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development. We can choose to continue paying the interest.

Or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

Q:Does it mean we must always have to put in a lot of effort upfront to make sure the design is good? Even for small / ‘quick’ projects?                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 

A:

It depends – factors like the project size, complexity, estimated effort, etc.  The following graph (from Mr. M. Fowler) can illustrate the trade-off :

The pseudo-graph plots delivered functionality (cumulative) versus time for two imaginary stereotypical projects: one with good design and one with no design. The project that does no design expends no effort on design activities, whether they be up front design or agile techniques. Because there's no effort spent on these activities this project produces function faster initially.

The problem with no-design, is that by not putting effort into the design, the code base deteriorates and becomes harder to modify, which lowers the productivity, which is the gradient of the line. Good design keeps its productivity more constant so at some point (the design payoff line) it overtakes the cumulative functionality of the no-design project and will continue to do better.

Q:What are the common causes of Technical Debt?

A:

Common causes of technical debt include (combination of):

• Business      pressures, where the business considers      getting something released sooner before all of the necessary changes are      complete, builds up technical debt comprising those uncompleted changes.

• Lack      of process or understanding,      where businesses are blind to the concept of technical debt, and make      decisions without considering the implications.

• Lack      of building loosely coupled components,      where functions are not modular,      the software is not flexible enough to adapt to changes in business needs.

• Lack      of a test suite,      which encourages quick and risky band-aids      to fix bugs.

• Lack      of documentation,      where code is created without necessary supporting documentation. That      work to create the supporting documentation represents a debt that must be      paid.

• Lack      of collaboration,      where knowledge isn't shared around the organization and business      efficiency suffers, or junior developers are not properly mentored.

• Parallel      development at the same time on two or more      branches can cause the buildup of technical debt because of the work that      will eventually be required to merge the changes into a single source      base. The more changes that are done in isolation, the more debt that is      piled up.

• Delayed      refactoring – As the requirements for a      project evolve, it may become clear that parts of the code have become      unwieldy and must be refactored in order to support future requirements.      The longer that refactoring is delayed, and the more code is written to      use the current form, the more debt that piles up that must be paid at the      time the refactoring is finally done.

• Lack      of alignment to standards,      where industry standard features, frameworks, technologies are ignored.      Eventually, integration with standards will come, doing sooner will cost      less (similar to 'delayed refactoring').

• Lack      of knowledge,      when the developer simply doesn't know how to write elegant code.

• Lack      of ownership,      when outsourced software efforts result in in-house engineering being      required to rewrite outsourced code.

• Poor      technological leadership      where poorly thought out commands handed down the chain of command      increases the technical debt rather than reduce it

• Last      minute specification changes;      these have potential to percolate throughout a project but no time or      budget to see them through with documentation and checks

Q:If we want to address the Technical Debt problem in the software development teams, what can we try ?

A:

Some software experts propose two techniques that can be used to reduce your debt:

Ø  programming in pairs and

Ø  code refactoring

The real value of pair programming is in reducing the technical debt. By pairing, team members broaden the areas of the codebase they are familiar with and increase overlap.

Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctionalattributes of the software. Advantages include improved code readability and reduced complexity; these can improve source codemaintainability

The value of refactoring is not just the reduction of technical debt. Refactoring is a great way of reducing competence debt too. It is only when you can change a system that you truly understand it.

Pair programming is a technique in which two programmers work as a pair together on one workstation. The two programmers switch roles frequently.

The idea is : instead of relying on code review / walkthrough AFTER the code was written , it is better to use ‘Pair Programming’ when the team is writing the programs. Pair programming is most suitable for the ‘critical’ software modules – e.g. transactions. On the other hand, pair programming are not effective for developing simple User Interfaces.