Ben Hosking writes in Managing Complexity – The aim of Designing Code that:

The most important part of design is managing complexity

I like the simplicity of that. What happens if you don’t manage complexity. Well, it starts to cost. Talking at OOPSLA 2004, Ward Cunningham (Mr. Wiki) compared complexity with debt:

“Manage complexity like debt,” Cunningham told attendees. Using this analogy, he likened skipping designs to borrowing money; dealing with maintenance headaches like incurring interest payments; refactoring, which is improving the design of existing code, like repaying debt; and creating engineering policies like devising financial policies.

In an interview with Bill Venners (Artima), Andy Hunt (Pragmatic Programmer) extends the analogy concisely:

“But just like real debt, it doesn’t take much to get to the point where you can never pay it back, where you have so many problems you can never go back and address them.”

It’s a lovely metaphor. But it does breaks down in one place. Project managers don’t get a pile of bills through the door every month. Even if they wanted to, they can’t rip them open, sum them up, compare them against income and outgoings and discover just how fragged they are, or even hell, that they can afford loads more debt!

Well it’s not quite that bad. We can at least measure and sum up the complexity of items at different levels of design breakout (methods, classes, packages, subsystems and projects).  We may not be able to put a hard complexity number on the tipping point (insolvency), but we can give you a number. With this you can compare projects, monitor trends that show where it’s getting more or less complex, and discover which items at what level are causing the trend.

For example here is the home page for the Structure101 Tracker web application showing the sizes and over-complexity of several projects:


Now, correlate XS with the depth of furrow on team leaders’ foreheads, and you’ve really got something to go on…


  1. Paddy

    We have been using the term “technical debt” in our agile projects for a while now. Its a really useful metaphor for people close to the code. The problem is that unless you have a way to quantify it it remains abstract and intangible at a management level. What I like about Structure101 is that it gives me a means to quantify and communicate technical debt to people outside the development team.

  2. Frank Kelly

    Hi Chris,

    I agree that the “debt” terminiology is very useful in Software Engineering as a whole – where decisions (or lack thereof) come back later (with avengence) if not addressed.

    I’ve blogged a little about this earlier this year – more focused on key design decisions and project planning.



  3. Haacked

    I’ve heard this called “Design Debt” which is pretty much the same thing.

    I wrote up an example here:

    Joshua Kerievsky has some great illustrations of this in practice in the book “Refactoring to Patterns”.

Leave a Reply

Your email address will not be published. Required fields are marked *

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.