Technical Debt isn’t a Technical Problem

Home » Agile Techniques » Software Architecture and Design » Technical Debt isn’t a Technical Problem
Photograph of columns in old building

I listened to an old podcast from Dot Net Rocks recently Technical Debt isn’t Technical with Einer Host, which went on to explain how Technical Debt isn’t a technical problem.

Using Agile techniques, once the sprint has been set by the product owner, programmers are left to themselves to organise the work and to slowly build the software feature by feature, while keeping a fully tested releasable version of the software available at the end of every sprint.

Wikipedia (https://en.wikipedia.org/wiki/Technical_debt) says:

Technical debt (also known as design debt or code debt) is a metaphor referring to the eventual consequences of any system design, software architecture or software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper”

Some technical debt is inevitable due to the nature of the very iterative, simplest method possible way of programming in Agile, but it is constantly re-factored out and improved upon as the work progresses. If it is not, it means the work done so far is probably adequate and the debt is a very small thing that works but possibly is not best practice, but is such a small thing it doesn’t really matter or affect anything.

There is another side to technical debt however, that is if the team is not really Agile, and there are problems with management interfering or trying to control work, or by trying to set deadlines rather than measuring velocity, then an amount of technical debt that can build up that eventually slows the project down to the point where further development work is very difficult, expensive and time consuming. This problem is as bad as not using good design in the first place due to having a very inexperienced team doing the work.

The Wikipedia article lists many more reasons for technical debt and the pod-cast was a very interesting listen. The common causes listed in the Wikipedia article all fall into two categories:

  1. Management Pressure to try to push or control things resulting in things being done in the wrong order or not at all
  2. Inexperience on the part of Developers

The answer? In my view, try to follow Agile practices as far as possible, because the more a project does something that is new, the more a project can benefit from Agile techniques. Agile techniques can handle uncertainty and change better than any other method we know. I also believe that seniors should work to support the whole team in terms of knowledge and ensuring they have enough time to carry out their work and also shield the team from management pressure (although not allowing the current sprint to be altered after it has started except by developers themselves goes a long way to doing that).

About Phil

I have been working as a software developer since 1983. This blog could have been called “From Fortran 77, C and Cobol to C# in 20 (not so) easy years”, but it doesn’t sound quite right somehow. Besides I’m talking about what’s happened since 2003, not before!

Leave a Reply

Your email address will not be published.


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">




Top Posts & Pages

Categories

Recent Posts

Recent Comments

Archives

Blogroll

  • Mike Cohn's Blog
  • Scott Hanselman's Blog
- mike@mountaingoatsoftware.com

Scrum teams have too many meetings is perhaps the most common criticism of Scrum. But is it valid? [...]

- mike@mountaingoatsoftware.com

Here are five key lessons I learned that were instrumental in my career. See if learning them could [...]

- mike@mountaingoatsoftware.com

A team’s sprints should be the same length every sprint. Here are four reasons why. [...]

- mike@mountaingoatsoftware.com

Read this special Halloween post about five things in agile transitions that are can seem as scary a [...]

- mike@mountaingoatsoftware.com

If you want to overcome problems and improve how you work with user stories, register now through Oc [...]

- Scott Hanselman

In 2016 and 2015 I made a list of best Christmas STEM Toys for kids! If I may say so, they are still [...]

- Scott Hanselman

I'm glad you have a 1080p 60fps accelerated graphics setup, but I'm old school. Impress me [...]

- Scott Hanselman

Visual Studio Code has a HUGE extension library. There's also almost two dozen very nice Azure [...]

- Scott Hanselman

I got an email this week asking how to download some of my Azure Friday video podcast videos from ht [...]

- Scott Hanselman

There's a couple of great utilities that have come out in the last few weeks in the .NET Core w [...]

Meta