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

Pervasive myths about agile get in the way of success. It’s time to bust six of those myths. [...]

- mike@mountaingoatsoftware.com

Agile teams strive to finish work in the same iteration in which its begun. Here’s why that is so im [...]

- mike@mountaingoatsoftware.com

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

- mike@mountaingoatsoftware.com

The iterative and incremental nature of agile makes an agile approach seemingly less compatible with [...]

- mike@mountaingoatsoftware.com

Velocity can be great for predicting how much a team can deliver in a given period. But it needs to [...]

- Scott Hanselman

I've been exploring nopCommerce. It's an open source e-commerce shopping cart. I spoke at [...]

- Scott Hanselman

The optical disc drive is giving out on my GoldStar 3DO machine. It's nearly 30 years old. I wa [...]

- Scott Hanselman

I've long blogged about the intersection of diabetes and technology. From the sad state of diab [...]

- Scott Hanselman

Back in the day, making a Minecraft mod was...challenging. It was a series of JAR files and Java hac [...]

- Scott Hanselman

I've been using ILMerge and various hacks to merge/squish executables together for well over 12 [...]

Meta