Feed Me
My Social Links
Twitter Feed

Entries in refactoring agile quality (1)


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)


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.