The strangulation of OSS feature releases

The diagram below provides a time-sequence view of how tech-debt accumulation eventually strangles new OSS feature releases unless the drastic measures described are taken.

The increasing percentage of tech debt

At start-up (t0), the system is brand new and has no legacy to maintain, so all effort can be dedicated to delivering new features (or products) as well as testing to ensure control of quality.

But over time (t0 + 10, where 10 is a nominal metric that could be days, years, release cycles, etc), effort is now required to maintain existing functionality / infrastructure. Not only that, but the test load increases. New features need to be tested as well as regression testing done on the legacy because there are now more variants to consider. You’ll notice that less of the effort is now available for adding new features.

The rest of the chart is self-explanatory I hope. Over a longer period of time, so much effort is required just to maintain and assure the status quo that there is almost no time left to add new features. Any new features come with a significant testing and maintenance load.

Many traditional telcos (Mammoths) and their OSS suites have found themselves at t0+100. The legacy is so large and entwined that it’s a massive undertaking to make any pivotal change (the chess-board analogy).

This is where startups and the digital / cloud players have a significant disruptive advantage over the Mammoths. They’re at t0 to t0+10 (if the metric is in years) and can roll out more new features proportionally.

What the chart above doesn’t show is subtraction projects, the effort required to ensure the legacy maintenance load and number of variants (ie testing load) are hacked away at every opportunity. The digital players call this re-factoring and the telcos, well, they don’t really have a name for it because they rarely do it (do they?).

Telcos (and their OSS suites) are like hoarders, starting off with an empty house (t0) and progressively filling it with stuff until they can barely see any carpet for the clutter (t0+100). It generally takes the intervention of an outsider to force a de-cluttering because the hoarder can’t notice a problem.

The risk with the Agile, DevOps, continuous release movement that’s currently underway is that it’s rapidly speeding up the release cadence so we might be near t0 now but we’re going to get to t0+100 far faster than before when release cadences were far slower.

Can we all see that an additional colour MUST be added to the time-series chart above – the colour that represents reductionist effort? I’m so passionate about this that it’s a strong thread running through the arc of my next book (keep an eye out for upcoming posts as I’ll be seeking your help and insights on it in the lead-up to launch).

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

6 Responses

  1. Excellent visualisation and description Ryan. As you point out in one of your earlier articles, the undiluted emphasis on technical perfection instead of an MVP approach clutters thinking, strategy and action. If a good Application Portfolio Rationalisation approach with the domain knowledge of OSS were to be applied (assuming that cost modelling is applied in the APR approach), we would actually be on a good wicket. That would mean that the “maintain legacy” piece in the t0+50 would surrender some of its territory to subtraction effort and some to new features.

  2. Hi Seshan
    So true!
    Can you recommend any good APR approaches? Have you seen any customers do this in a sophisticated way that’s worth describing?

  3. Hi Ryan, the honest answer is no, I’ve not seen it successfully implemented in a scientific manner; I have however seen some fit-for-purpose elements. E.g. one customer followed something close to the subtraction approach in a limited way. They took advantage of changing network technologies to limit use of an older system progressively – it got marginalised to the point that the majority of its functionality went into disuse. The impact was felt more in cost avoidance than actual savings and it did not result in the system being shut down, but it was an example of a subtraction approach. While I’ve learnt the term from your blog, I think it’s the correct way of approaching the technical debt in the OSS landscape and in my past efforts I’ve tried to apply this thinking. My view this is the way things will start panning out as we hit 2018 and 2019.

  4. Hi Seshan,

    I think there’s a fundamental flaw about how we think about subtraction projects… We always get funding to build the new one and then remove the old one afterwards… but does that make sense?
    Here are a few old links that give some of my perspectives…
    https://passionateaboutoss.com/seems-obvious-to-me-but-how-would-you-handle-this-migration/
    https://passionateaboutoss.com/the-first-step-on-the-path-of-simplification/
    https://passionateaboutoss.com/hotel-california-oss/

  5. True Ryan – the attitude where subtraction is confused with functionality migration in systems and is embedded in projects. I agree this is the wrong way to look at it.

    Dedicated funding to clean out the clutter is necessary – in functionality, data, integration, product-service portfolios, in processes, organisation structures. Interestingly the reason I brought up the example in my earlier response is that the group I was fortunate to be associated with was busy doing exactly that. Owing to the nature of the organisational maturity, they had to bring in some level of “new project / migration” aspects but the work they did focused on simplification and minimising duplication. Being prophets in a time of plenty, they didn’t make the headway they may have made otherwise and eventually the group scattered. But their work was based on their thinking and navigating the organisational waters. Unfortunately it didn’t get codified into a method, but I’m busy reusing some of it for work I’m doing with a client early next year.

    Since the days of largesse have disappeared, I’ve found much greater willingness in service providers here to look at de-cluttering the landscape owing to pressures from clients about flexibility, speed in time to market, accuracy, etc.

  6. Great to hear that you’re seeing a greater willingness to de-clutter there Seshan!!
    Hopefully my upcoming book themed around this subject will find an interested audience 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.