Feed Me
Login
My Social Links
Mugshot
Twitter Feed
« Agile Transformation - a story told from the trenches | Main | Business Value & Quality are the same: Convincing the Organization »
Wednesday
Aug032011

Making a Business Case for Refactoring

Here is the business case i recently made for a necessary refactoring in our platform that emerged after the project scope was approved. This may be of additional interest to others that consider Business POs to be the sole source of prioritization in a complex matrixed organization.

The Epic Story can be described as:  “As a developer, i want the cost of adding a new <product> to the platform to be as cheap as possible, so that we can deliver to market quickly and so that we can deliver on our promise of high quality.”

Cost of refactoring = 50-75 SP

Reduced cost for adding future products= –20SP

The immediate response from Product Owners or Project Managers is to balk at the cost and to bemoan the effect it will have on approved delivery dates. Typically, after considerable humming and hawing, handshake deals are made to preserve the Iron Triangle without admitting to the quality concessions that are necessary. Where have we seen this before? It almost sounds like an endemic decision tree that perpetually afflicts our industry.

The impact this decision has on quality is worse than one might believe. The cost calculation is compounded with each successive backlog that does not implement this new software pattern. That is to say it is exponential, not linear.

Let's look 2 years into the future and assume we'll deliver 3 products / year.

Base Cost of implementing new product with older pattern = ~40SP

(+) escalating cost of low maintainability code = x^3+10

(+) escalating cost to quality and QA efforts = x^3+10

If x=1 for the first product of that year, then this project will incur an additional 22 SP in rework, for a total of 40+22 = 62 SP.

x=2 --> 36 SP

x=3 --> 74 SP

x=4 --> 148 SP

x=5 --> 270 SP

x=6 --> 452 SP

Cumulative Cost = 1000 SP (you can probably argue the math and the numbers used, but you cannot argue the exponential decay to quality)

What this leads to, of course, is another House of Cards Platform waiting to happen, and the resulting paralysis that is often faced when trying to approve a new project. This is a pattern of decay that a lot of organizations follow, and these are the types of decisions, when not acted upon, that lead  to large 6000+ SP replatforming efforts. Perhaps we finally see how the cost of Refactoring now seems small compared to the alternative.

This is why Engineering/Architecture will always have the legitimate case to push for 'Technical' POs on a given backlog. Tech debt has increasingly been associated with 'optional' engineering work to help address token quality concerns, but the truth is that we are trying to independently select work that has a definitive impact on business value - albeit through reduced cost and time to delivery, if not directly through user NPS scores. We are ensuring that the derivatives market for an organization remains healthy, if not the present stock price.

So, we have 2 choices here. We either pay for the cost of this refactoring now, or we pay for it later. The cost in choosing the latter paints an awful picture above.

1. The trade-off is between short-term business need (revenues / time to market) with intentional decrease in platform quality (must pay for it later)

AND

2. Long-term health and stability of the product while possibly missing initial product launch dates

I'm ok with either decision, as long as we understand the ultimate cost to the future of our products, our quality, and our delivery times. Ultimately, the business must make the best decision here, and with enough trust between these groups, i am confident that it will always be the right one.

PrintView Printer Friendly Version

EmailEmail Article to Friend

References (7)

References allow you to track sources for this article, as well as articles that were written in response to this article.
  • Response
    Response: weblink
    Great Website, Keep up the beneficial work. Many thanks!
  • Response
    855 You will need 9 dark strips and eight white strips with the weave. The only real persistent that remains within our children's life, yr in, yr out, totally louis vuitton appears to be to always be their just about phobic distaste for going for walks.
  • Response
    Stochastic Rippling - .self - Making a Business Case for Refactoring
  • Response
    Stochastic Rippling - .self - Making a Business Case for Refactoring
  • Response
    Response: frank dellaglio
    Stochastic Rippling - .self - Making a Business Case for Refactoring
  • Response
    Response: Dr. Patel DDS
    Stochastic Rippling - .self - Making a Business Case for Refactoring
  • Response
    Response: best stocks
    Stochastic Rippling - .self - Making a Business Case for Refactoring

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>