Head First Agile: Is Technical Debt a good or bad thing?

[Junilu Lacar]

The subject line is really meant to be rhetorical and intended to get some responses about two different ways of viewing technical debt.

Contrary to what most people think it means these days, technical debt, or more accurately "The Debt Metaphor," was supposed to be a good thing, as Ward Cunningham explains in this short video.

Semantic Diffusion has flipped the original sense of the term so that nowadays, the term "technical debt" usually has a much more negative connotation. It seems like the book takes the latter view of technical debt, too. I think that's unfortunate because I find that leads to a more reactive/defensive rather than proactive/constructive mindset.

Certain kinds of technical debt is something that you actually want to have, at least temporarily, so you can facilitate the kind of learning that can only be gained through experience with software that you can actually run, exercise, and observe.

[Jeanne Boyarsky]

Well, there's the amount of debt. Many teams have more than is healthy...

[Junilu Lacar]

I think that the term got co-opted by many developers to refer to messy code.

Ward Cunningham wrote:In other words, the whole debt metaphor, let's say, the ability to pay back debt, and make the debt metaphor work for your advantage depends upon your writing code that is clean enough to be able to refactor as you come to understand your problem.

The problem with what many people now refer to as Technical Debt is that it's not what Ward talks about there, it's just messy code.

[meenakshi sundar]

I think that the term got co-opted by many developers to refer to messy code.  

Yes, I certainly agree that, i want to add to that some of the following as well fall into the Technical Debt category

Messy design

Wrong set  of tools

Early Refactoring

[Junilu Lacar]

I can see how you would consider messy designs and wrong set of tools as technical debt. I don't get how early refactoring can be considered as debt though. Did you mean premature optimization?

People often conflate refactoring with optimization. They are not the same. Michael Feathers explains the distinction in Working Effectively with Legacy Code book. Basically, refactoring is improving the internal structure of the code so that it's easier to understand and maintain, without changing functionality. Optimization has similar mechanics as refactoring but the goal is to improve the use of resources.

[satya Priya Sundar]

My take on Refactoring is

You write code with two hats on. "The just get the thing working hat" and the "I need a better understandable code for tomorrow "hat.
Obviously, the second hat is the refactoring one. So you refactor every time you have made something work but have inadvertently
introduced smells like duplicated code, long methods, fragile error handling, bad variable names etc...

Refactoring whilst trying to get something working (i.e. wearing both hats) isn't practical for non-trivial tasks.
But postponing refactoring till the next day or week, iteration is very bad because the context of the problem will be gone from your head.
So switch between hats as often as possible but never combine them.

Warm Regards
Sathya

[Vaseem Mohammed]

What is the time we should work on the TechDebt when we are in a middle of a project?

[Marco Behler]

I'd also like to add that in software teams, it sometimes is really difficult to tell what exactly "technical debt" is. Unfortunately, from my experience, IT people who get too removed from business, too removed from the outcome, from $$$, can basically endlessly discuss about technical debts, the ideal software project, the ideal code base etc. all day long and then build up a huge technical debt backlog - none of which is actually real debt. Sometimes it's simply ivory tower optimzations.

That of course doesn't mean you shouldn't fix/refactor a messy codebase, but I find the term "technical debt" simply too vague.

[Junilu Lacar]

Vaseem Mohammed wrote:What is the time we should work on the TechDebt when we are in a middle of a project?

Ideally, when you are in the middle of the project.

There are many pragmatic considerations though, including scope, time, and effort. Too often, however, people have a tendency to think that refactoring really messy code requires too much effort, that the pressure of meeting a deadline preempts any and all efforts and/or desires to refactor. Many developers either forget or don't realize that habitually spending a few minutes or seconds to rename, rearrange, or clarify code, no matter how insignificant they may seem in the small, can have very significant cumulative effects.

It's like that message that the annual Wikipedia donation drive says: If everyone who used Wikipedia donated $3, they could reach their funding goals in a few minutes. The problem is, most people ignore that message. Likewise, most developers ignore small opportunities to refactor, even though it would take them only a few minutes or even seconds to rename or extract something.

[Junilu Lacar]

Marco Behler wrote:That of course doesn't mean you shouldn't fix/refactor a messy codebase, but I find the term "technical debt" simply too vague.

The vagueness you refer to can sometimes be due to a lack of recognition and/or definition. Developers will often feel the effects of having too much unmanaged technical debt but fail to recognize or respond to it or there can be so much going on at once that they don't know which problems to address first.

When I started out with my current team, there were many problems that were slowing us down. Rather than just try to keep muddling through and bitching and moaning about it all the time, we sat down in a retrospective and identified our biggest pain points. The first one we identified was a long, tedious, error-prone manual build. So we set a goal of moving to Maven and setting up an automated build server. More retrospectives followed and with each one, we identified and addressed one or two pain additional pain points, always picking the ones that were most painful to us.

I don't know if anybody has ever achieved pain-free development. There's always something that can be improved. It's just a matter of deciding how much pain and discomfort you're willing to tolerate and slow you down.

[meenakshi sundar]

Exactly, i sure agree with both these points, it speaks of the same lethargic mindset developers tend to have.

Many developers either forget or don't realize that habitually spending a few minutes or seconds to rename, rearrange, or clarify code, no matter how insignificant they may seem in the small, can have very significant cumulative effects.  

But postponing refactoring till the next day or week, iteration is very bad because the context of the problem will be gone from your head.
So switch between hats as often as possible but never combine them.  

[Tim Holloway]

I have a client that has not merely heavy technical debt, but literal debt (they owe me enough to re-roof a house). Their database is no longer supported by the vendor, their appservers are nearing end-of-life, the framework that supports their web GUI is no only long past end-of-life, it's explicitly indicated that it does not and never will support anything newer than Internet Explorer 8.

I don't really understand them, since every time I've checked in, their database (and customer base) has gotten bigger, but despite repeated warnings, they've done nothing to update anything. Oh, and the database is a Community Edition release, and I'm not sure how long the "freebie" edition can go on before they hit the built-in capacity limits.

Some day this thing is going to blow so hard that President Trump will phone Kim Jong Un and ask what happened. Everything's going to break at once and it won't be something you can band-aid, it's going to require literally months of redesign and coding.

I've seen - and been wearied - by situations where you have systems so complex that one or more components could be updated daily (if permitted, this would be one of them). But letting everything slide like this borders on criminal. These are people with large-computer IT backgrounds and they should know better. I'd say that they're just planning to ride until it blows, then bail, but the way they're set up at the moment looks like all that would do is get them sued from every direction at once.

[meenakshi sundar]

For sure we have all seen and experienced these situations before, some of my earlier work involved working with these kinds of
application with smokiness

The willingness to address those issues though it was out in the open, never bothered the decision makers ,They were blinded by
the plan, budget, customer satisfaction........ this list goes on :-(
it eventually ended up as a big mess to clean at the end ....as mentioned by Tim

Everything's going to break at once and it won't be something you can band-aid, it's going to require literally months of redesign and coding.  

How do we handle the situation ?

[Junilu Lacar]

Situations like that are really where Agile crashes into Reality. It's going to take a whole lot more than principles/values, process frameworks, practices, and platitudes to get you out of messy situations like that.

[Andrew Stellman]

Tim Holloway wrote:I've seen - and been wearied - by situations where you have systems so complex that one or more components could be updated daily (if permitted, this would be one of them). But letting everything slide like this borders on criminal. These are people with large-computer IT backgrounds and they should know better. I'd say that they're just planning to ride until it blows, then bail, but the way they're set up at the moment looks like all that would do is get them sued from every direction at once.

Yes!! This is exactly why we treat technical debt the way we do in Head First Agile – I've run across many teams like this. I absolutely get why Ward Cunningham initially proposed technical debt the way he did, using a metaphor that assumes that not all debt is bad. But the reality is that most teams aren't using debt the way you'd use a home equity line of credit to redo a kitchen and increase your home's value. They use it like they're taking an almost maxed-out credit card on one last shopping spree.

[Junilu Lacar]

Since Ward's motivation for "going into debt" was to be able to get experience with the working program earlier, learn from that experience, then use what was learned to pay back the debt, I like the metaphor of taking out a student loan to earn a degree. Getting a degree means you learned something of value. When you take out a loan you can go to school and earn a degree that you couldn't have otherwise. When you have your degree, you can get a good job and earn decent money which allows you to pay back your student loan and eventually improve your economic situation.

If you take out the loan but don't put in the work to earn a degree, then you blow the opportunity that taking out the loan afforded you. What's worse, the "technical debt" people usually refer to is really like money you owe to a bookie or loan shark that you didn't pay in time. The longer it takes you to pay the bookie or loan shark back their money, the more you owe them and you just keep getting deeper in the hole. Now you're in trouble and risk getting your legs broken or worse.

When "technical debt" is taken in a negative context, it's usually because developers "took out the loan" but never did anything to "earn the degree." I wish there was some way to get people to stop using "technical debt" to refer to what's really just a "technical mess."

[Elisabeth Chin]

Junilu, I completely agree. It takes balance and wisdom to manage technical debt well. But it can and should be used to the advantage of developers and businesses. We wrote this article explaining some advantages of technical debt as well as potential pitfalls: https://praxent.com/blog/brief-history-technical-debt / What Is Technical Debt: The History & Definition. One of those advantages is that, when properly incorporated into a workflow like Agile or Scrum, technical debt can help teams adapt quickly to new discoveries.