The Agile Executive

Making Agile Work

Can You Afford the Software You are Developing?

with 15 comments

A reader of The Agile Executive brought up some questions about product retirement in the context of  project teams that use Agile methods. For example: Should a product backed by a hyper-productive Agile project team be retired at the same point that an aging Waterfall product typically would?

The question is important. Customers can get very upset over the retirement of a product, particularly a mission-critical product. Even if the vendor offers a new product that replaces the one to be retired, the operational disruption associated with migrating to the new product is often troublesome. On the other hand, the cost of maintaining software, let alone keeping it current, could be and is often high for the enterprise software vendor.

The answer to the product retirement question ties Agile methods and practices to the fabric and economics of software engineering.  A good way to address the subject is to ask the following two questions:

  • Can you afford the software you are developing now?
  • Would you be able to continue to adequately invest in the software as it evolves down the road?

Rules of Thumb for Affordability

Affordability is, of course, in the eyes of the beholder. Your CFO might see it in quite differently than your CMO. To bring a discussion between the two, or any other forum of CXOs, to a common denominator, you need to get a handle on two numbers:

  • Development cost (including product management and test costs) per story card
  • Development cost as a percentage of product life-cycle cost

Development costs and life-cycle costs vary greatly from one company to another as well as within your company. For example:

  • Off-shore costs can be quite different from on-shore costs
  • The costs of maintaining high quality code are drastically different from those for average quality code. (See Estimating Software Costs by Capers Jones for a detailed analysis of the subject).
  • Productivity of an Agile team can easily eclipse that of a Waterfall team.

Laborious and time consuming that collecting good cost data across development methods, projects, sites and continents might be, you are essentially flying blindly with respect to affordability unless you have very specific cost data.

Until you gather this data, here are two rules of thumb that can be used to get a rough sense of  affordability:

  • A typical figure for development and test cost per story card for enterprise software project teams is thousands and thousands of dollars. It can exceed $10,000.  This (order of magnitude)  figure is for a contemporary software development and test organization in the US that is “reasonably” balanced between on-shore and off-shore development
  • Development cost is typically less than 50% of the total software life-cycle costs. Again, the assumption of reasonable balance between on-shore and off-shore applies

These rules of thumb should be used prudently. For example, Mens and Demeyer report cases in which software development costs constituted a mere 10% of the total life-cycle cost.

What is your Software Evolution Strategy?

In Program Evolution: Processes of Software Change, authors Lehman and Belady summarized years of research on the subject they and various collaborators carried out. Their bottom line is deceptively simple: software is live and always evolving. Furthermore, software decays.

Jim Highsmith uses the following great graph to demonstrate the effect of accrued technical debt on cost of change and responsiveness to customers:


Jim points out that no good option exists once the software has decayed to the point of excessive technical debt. Furthermore, once you are in the far right of curve estimation is next to impossible and afforability calculations become pretty useless. You might think about technical debt like debt on a credit card – you become a slave to servicing the debt instead of paying off the principal.

Affordability Revisited

Between the initial development cost and the cost of evolving and maintaining decaying software, many software development projects find themselves in dire need of higher productivity. Hence, a more precise statement of affordability is as follows:

  • Can you afford the software you are developing given your productivity during and after development of the first release?

The productivity results reported for companies successfully using Agile methods such as  BMC SoftwareSirsiDynix and Xebia indicate productivity gains of at least 2X, and often higher, compared to industry average. Everything else being equal you would be able to retire a product backed by a good Agile team later than a product backed by a Waterfall team.

Many Agile teams tend to be inclined to refactor the code on an on-going basis. For example, Salesforce devotes about 20% of development resources to refactoring. As a result, software decay is slower for such teams. They reach the point of no good options in Jim Highsmith’s graph later than teams who do not refactor the code day in and day out.

Refactoring is like flossing your teeth regularly. The dental tape disconnects your bank account from the dentist’s…

About these ads

Written by israelgat

February 1, 2009 at 9:46 pm

15 Responses

Subscribe to comments with RSS.

  1. [...] It’s been interesting, and fun, this week to watch which Twitter’ed links people click on. For example, this one has been the most popular so far. [...]

  2. [...] As you and your software team/organization undoubtedly ask the core versus context questions in your business, I have been providing thinking tools for analyzing your portfolio in these turbulent times.  As Israel Gat pointed out in his recent post, “Can you afford the software you are developing?“ [...]

  3. [...] Can you afford the software you are developing? (from Israel Gat’s blog) [...]

  4. [...] Technical debt [...]

  5. [...] a comment » Readers of the post Can You Afford the Software You are Developing? might recall my grave concern about accruing technical debt. It is like debt on your credit card – [...]

  6. An interesting corollary to this idea of cost deals with how much productivity gain can be achieved by introducing Agile techniques late into an aging product. While Agile will extend the life of a product, I would propose that a software development team’s ability to be agile is inversely proportional to the amount of legacy code they maintain.

    Mike Lunt

    March 12, 2009 at 1:14 pm

    • Capers Jones [2008] points out that Web applications are often Agile applications. At this point in time the average age of Web applications is 5 years. It will be fascinating to watch geriatric effects in Web applications in the coming years. It is not necessarily clear that Web application will follow the behvior of traditional legacy applications.


      March 19, 2009 at 11:40 am

  7. [...] life cycle costs of software, asking the executive I am speaking with to answer a tough question: Can you afford the software you are developing?  This question often leads the executive to reexamine the balance between the two strategies [...]

  8. [...] Can your company afford the software it is developing? [...]

  9. [...] need to ask yourself the question “Can We Afford the Software We are Developing?“ if business circumstances do not allow for reasonable adherence to the principles cited [...]

  10. [...] time to get into refactoring big time. If you don’t, sooner or later you are likely to find you can’t afford the software you developed. Possibly related posts: (automatically generated)Lean AgileFree Software Foundation throwing a [...]

  11. [...] a comment » Only three options are available to you once your technical debt overwhelms the development and customer support [...]

  12. [...] defects in the enterprise software products you license. If the technical debt figure is high, the vendor you are considering might not be able to afford the software he has developed. Under such circumstances, “premium services” could simply be a vehicle the vendor [...]

  13. [...] is time to get into refactoring big time. If you don’t, sooner or later you are likely to find you can’t afford the software you developed. Possibly related posts: (automatically [...]

  14. [...] you accrued organizational debt: It is conceptually quite similar to accruing technical debt – various organizational decisions and compromises taken along the way were rushed to the [...]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 36 other followers

%d bloggers like this: