Mar 222010

Source code analysis techniques have progressed to the point that answers to numerous tricky questions about software investment dilemmas can now be answered through quantifying technical debt.  Consider, for example, the following scenario:

  • You are a venture capitalist.
  • One of your portfolio companies has been working for a few years now on a promising software application.
  • Various surprises with respect to schedule and functionality have been sprung on you along the way.
  • The company asks for additional $2M to complete development and bring a 500K lines of code to market.
  • Using technical debt quantification techniques you find the technical debt amounts to $1M.

You are not at all comfortable “paying back” the technical debt in addition to funding the requested $2M. You wonder whether you should start afresh instead of trying to complete and fix the code.

A good starting point for assessing the start afresh option is Michael Mah‘s studies of software productivity. Based on the QSMA SLIM metrics database of more than 8,000 projects, Michael will probably bracket the productivity per person in a team consisting of product management, development and test at 10-15K lines of code per year. If you use the 15K lines of code per year figure for the purposes of the analysis, 500K lines of code could theoretically be delivered with an investment of about 33.3 (500/15) man years. Assuming an average loaded cost of $99,000 per man-year, the software represents a programming effort of $3.3M. Not much is left if you deduct $3M ($2M+1M) from $3.3M…

Six considerations are of paramount importance to properly evaluate the start afresh option:

  • The comparison above ($3.3M versus $3.0M) is timeless. It is a snapshot at a certain point in time which does not take into account the value of time.
  • Your “mileage” may vary. For example, best in class teams in large enterprise software projects such as BMC’s (see figure below) have reported productivity of 20K lines of code per team member per year. As another example, productivity in business applications is very different from productivity in real-time software.

Agile Productivity Indices v. Industry Average

  • If you decide to start with a brand new team, remember Napoleon’s quip: “Soldiers have to eat soup together for a long time before they are ready to fight.”
  • If you decide to start afresh with the same team plus some enhancements to the headcount, be mindful of  ‘Mythical Man-Month‘ effects. Michael’s studies of the BMC BPM projects indicate that such effects might not hold for proficient Agile teams. Hence, you might opt to go Agile if you plan to enhance the team in an aggressive manner.
  • Starting afresh is not an antidote to accruing technical debt (yet again…) over time. But, it gives you the opportunity to aggressively curtail technical debt by applying the techniques described in Using Credit Limits to Constrain Development on Margin. For example, you might run source code analytics every two weeks and go over the results in the bi-weekly demo.

As long as you are mindful of these six aspects (timeless analysis, your mileage may vary, Napoleon’s quip, mythical man-month, credit limits on technical debt and the value [as distinct from cost] of software), combining technical debt figures with productivity data is an effective way to consider the pros and cons of “fix it” versus starting afresh. The combination of the two simplifies a complex investment decision by reducing all considerations to a single common denominator – $$.


Israel Gat

Israel Gat served as Cutter Fellow and the Director of the Agile Product Management & Software Engineering Excellence practice from 2008 until 2015.


  4 Responses to “Quantifying the Start Afresh Option”

  1. […] Pro Tweets New blog post: Quantifying the Start Afresh Option cuttertweets – Mon 22 Mar 17:50 All Things […]

  2. “The software, warts and everything, might (or might not) be valuable to the target customers.”


    Windows 95 was years late, full of defects, saddled with the legacy of DOS… and wildly successful. It was the right product at the right time.

    Windows Vista took about 6 years to develop, contained considerable amounts of rewritten code to address security issue, was widely beta-tested to help with quality… and the world couldn’t get Windows 7 fast enough.

    That’s just one contrasting example. I’m sure there are tens of thousands.

  3. […] to for sometime now (see Beyond Scope, Schedule and Cost: Measuring Agile Performance and Quantifying the Start Afresh Option). The heart of both the technical debt service and the enlightened governance framework is captured […]

  4. […] a comment » ??Recent posts in this blog and elsewhere recommended using technical debt (TD) criteria as an integral part of the build process. One could […]

 Leave a Reply

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>