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

I wrote 24 blog posts during 2019. In case you missed some of them, here are the most popular. [...]

- mike@mountaingoatsoftware.com

It’s coming on Christmas. That time of year when I drop hints to my family about gifts I’d like. [...]

- mike@mountaingoatsoftware.com

[...]

- mike@mountaingoatsoftware.com

As useful as user stories can be, they’ve never been right for every team. An exciting alternative f [...]

- Scott Hanselman

Hey! Did you know I have a podcast? A few actually but Hanselminutes has been doing for over 700 epi [...]

- Scott Hanselman

Now that .NET Core 3.1 is LTS (Long Term Support) and will be supported for 3 years, it's the r [...]

- Scott Hanselman

I did a post on the difference between a console, a terminal, and a shell a while back. We talk a lo [...]

- Scott Hanselman

I've blogged about the importance of the LED Moment. You know, that moment when you get it to b [...]

- Scott Hanselman

Following up on my post last week on moving from App Service on Windows to App Service on Linux, I w [...]

Meta