Sometimes you get into a scenario where a software team is iterating quickly and delivering lots of software. Over time, failure to do housework and paying off technical debt leads to productivity going down.

They eventually approach a point where all the resources of team are used up in overcoming the accumulated cruft just to deliver simple changes.

This appears to be a tipping point in technical debt. An associate referred to it as the agile iterative cliff - but that doesn't register on Google.

My question is: What is the standard terminology for the scenario of the agile iterative cliff?

  • 6
    The term is "technical debt". After all, you talk about a problem only when it's sizable, most often when it's the biggest problem you have. Therefore there is no particular expression for "crippling technical debt" versus just "technical debt". Sep 12 '16 at 11:11
  • 9
    By analogy, I suppose it would be technical bankruptcy. Sep 12 '16 at 12:00
  • Not sure about the terms, but read this: ronjeffries.com/xprog/articles/refactoring-not-on-the-backlog Sep 15 '16 at 6:20
  • This is a typical problem for less experienced developers or managers. This problem has probably been in existence as long as software has existed; it is one of the mistakes people make, and learn from, repeatedly. Nothing to do with agile. Sep 15 '16 at 21:41

The term gridlock seems appropriate. Mind that I just made this up, it is not a broadly accepted term for the situation you describe.

You keep adding scenario bound quick and dirty fixes until you reach a state that does not allow another quick fix without breaking something else. So there is no longer a possibility to make a move by just tweaking something, you have to take the whole thing apart and start over.

I call the methodology that leads to this situation "rushing to the exit". No analysis is performed, nothing is modelled, issues are addressed ad hoc, one at the time, until they stop coming in. If they do not stop coming in before gridlock, you have an expensive problem.

As Frank pointed out, this is not equivalent to agile. Agile does not mean stupid, lazy or reckless. Agile is just a formalized way to not let formalities/overhead gridlock your project. If done properly it even reduces the risk of technical gridlock.


I've never heard of that term, which is probably because it doesn't make too much sense - in my experience there is no tipping point. It's a gradual thing.

The only real tipping point happens once you realize that technical debt exists and you need to get rid of it. At that point your productivity will fall massively, because at the same time you need to refactor the software, retrain your software engineers, and take a more measured approach when working on new projects.

If that realization doesn't happen, the entire thing is usually called a death march, but that is a rather generic term which encompasses various kinds of failures, not just technical debt. It describes a failed company/project/software where the people in charge have yet to realize it failed, and generally try use the same methods to save it which they used to run it into the ground.

  • I always thought of "death march" as a type of project management, or a type of management. Basically, keep increasing the frequency of the meetings to discuss the scheduling problem until either no progress can be made (due to meetings), or everyone of importance has quit. Sep 14 '16 at 21:48

It sounds like a death march with infinite defects methodology.

Joel explains it here like this

The very first version of Microsoft Word for Windows was considered a "death march" project. It took forever. It kept slipping. The whole team was working ridiculous hours, the project was delayed again, and again, and again, and the stress was incredible. When the dang thing finally shipped, years late, Microsoft sent the whole team off to Cancun for a vacation, then sat down for some serious soul-searching.

What they realized was that the project managers had been so insistent on keeping to the "schedule" that programmers simply rushed through the coding process, writing extremely bad code, because the bug fixing phase was not a part of the formal schedule. There was no attempt to keep the bug-count down. Quite the opposite. The story goes that one programmer, who had to write the code to calculate the height of a line of text, simply wrote "return 12;" and waited for the bug report to come in about how his function is not always correct. The schedule was merely a checklist of features waiting to be turned into bugs. In the post-mortem, this was referred to as "infinite defects methodology".

It's not a new concept. This was long before the "agile manifesto" or any other newfangled jargon from the 2000s. (You Dang Kids Get Off My Lawn.)

  • Maybe the Agile Manifesto itself came from the 2000s, but most of the ideas behind it were around for much longer than that. Agile was a 90s idea. Sep 15 '16 at 21:08
  • 1
    The first version of Word for Windows was released in 1990. I am writing about 1980s ideas. Personally I think "Agile" was rebranding of some very old ideas but that could be just me...
    – MarkJ
    Sep 16 '16 at 9:58

The generic term is bad software engineering. It really has nothing to do with agile or any other methodology. You can create this problem with any methodology.

I put this answer here as a counter to the term "technical debt." I don't like that term as it implies that the "debt" (i.e. poor design) is inevitable.

  • Yeah, except pretty much everyone bolts on something for add a new feature or fix a defect. Then bolts on a bit more... and its all fast and easy and going well. And then one day it gets hard and it's refactor time. Easy to argue after the fact that this should have been done earlier - but that's just the benefit of perfect hindsight. Sep 15 '16 at 1:54
  • 1
    @quickly_now - No, that's not hindsight. That's the advice given by almost every guide I've ever seen on how to perform agile development: every time you finish working on a piece of code, look over how your project is going and do a bit of refactoring to improve it. It's right there, as part of TDD, the single process that almost everyone agrees is one of the most critical core practices of agile. Red, green, refactor. If you wait until you have a problem to refactor, you're ignoring the basic practices of the field. Sep 15 '16 at 21:02
  • Personally I think the problem, and solution, are independent of development methodology. It is simply a question of whether you value code that can be proven correct, versus correct results for a specific set of inputs. I do not believe we can generalize and say that accumulating "technical debt" leads to faster development; for some projects, it can kill development outright. Sep 15 '16 at 21:24
  • @quickly_now "pretty much everyone" does not work the way you describe at all. This is your method, or your team's method of working. Developers who write reliable software try to get each iteration in a good state before moving on. This is standard practice. When someone tells you "we can clean it up later," or worse, "don't worry, this is throw away code," don't believe them. Sep 18 '16 at 16:32
  • @Frank: I think you misunderstand me. Things tend to happen, fit, work, and work well. But that can't and does not ever go on forever, thats pretty much the point I was trying to make. Even doing things well, no code can endlessly take evolving changes in requirements or features without a pause for some bigger work at some point. I COMPLETELY agree WRT "throw away code" (which isn't), and "clean it up later" (which never happens). I've been the victim of such an attitude - cleanup up after others, to never ever want to do such things. Sep 22 '16 at 3:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.