Wednesday, February 23, 2011

The Impact of Accidental Complexity on Estimates

At speakerconf Aruba, J.B. Rainsberger recently gave an enlightening talk which included discussion on the impact of accidental complexity to estimates.

In his talk, he pointed out that estimates are composed of accidental and essential complexity. It's often easy to estimate the essential complexity of a problem; however, estimating accidental complexity is an entirely different matter. This point really hit home for me. On my last project I often strongly disagreed with certain members of the team on estimates. I was often higher than the average, and much higher than the lowest estimates. J.B.'s talk really openend my eyes to a few points.
  • Not all developers consider both accidental and essential complexity while estimating
  • Features that touch accidentally complex portions of the system are harder to estimate as the accidental complexity can often be hard to completely understand. (If you completely understood it, you'd probably remove the accidental complexity)
  • Introducing technical debt increases accidental complexity, and as a side-effect invalidates previous estimates and increases the likelihood that future estimates will differ in size drastically.
The first two points had always been intuitive to me; however, it was good to hear the ideas clearly articulated from someone else's point of view. The last point was the one that really interested me.

I'm lucky enough to work for a company where I don't need to explain the benefits of addressing technical debt. As developers we sometimes consciously introduce technical debt when it will allow us a short-term benefit, and we address that technical debt when appropriate. I've always considered technical debt to be part of the developer's world, and I only mention it to the business when completing a feature takes longer than expected due to tech debt. I never considered the impact of technical debt on my ability to produce accurate estimates for the business.

J.B.'s talk made me ask myself a few questions about decisions I'd been making. Most importantly: If the business knew that I was taking a short-cut to deliver sooner, but it was going to damage estimates, would that be acceptable? I think that's an important question to consider if your client values estimates, and it's something I'll continue to ask myself in the future.


  1. Nice post Jay! Never heard of those terms before in the context of technical debt. Cheers, Ross.

  2. Anonymous6:05 AM

    Martin Fowler's article on technical debt is a must read for any software developer, elearning or not:

    Note that good practices don't necessarily take more time. They don't necessarily get in the way of getting things done fast. Minimizing technical debt is more a question of self-discipline.

  3. I didn't hear JB's talk, but it seems like what he's touching on with accidental complexity is what's supposed to be represented in the spread between "aggressive but possible" and "highly probable" when you're making range estimates.

    It uses different language (50% and 90% confidence) but I described that idea in a blog post on making better estimates.

  4. It seems there should be some kind of a relationship between reducing technical debt and the YAGNI principle. Knowable technical debt are the problems you know you have introduced, but the perfect is also the enemy of the good.

    Technical debt is a fantastic concept but is it also unrealistic to suggest one should aim for zero?


Note: Only a member of this blog may post a comment.