In the world of software development, the topic of end-of-life scenarios often remains overlooked and there is a stark absence of guidance or case studies to help navigate such situations effectively. This series of blog posts aims to fill this gap, drawing from my own experiences across various companies.
Software End of Life Part 1: The Journey to Closing Down a Legacy Product delves into managing a legacy software product closure, navigating challenges and strategies to retire outdated systems and transition to modern solutions.
Software End of Life Part 2: Overcoming Tech Debt With a Complete Rebuild looks at what to do when the burden of tech debt becomes so overwhelming that a complete product rebuild becomes the only viable solution.
Software End of Life Part 3: From Abandonment to Open Source Revival outlines the transformative journey of leveraging open source to breathe new life and opportunity into a product acquired and later abandoned by its new owners.
Grappling with the burden of tech debt
I found myself in the situation of leading a small team maintaining an e-learning authoring product that was held back by significant tech debt. The team could only watch in frustration as the world moved onwards but their own product just could not maintain pace. Building learning content with the tool had become so cumbersome that it was hard to run customer projects profitably.
Something had to be done. The initial task of estimating how we could fix the product revealed the true scale of the work, and conversation quickly moved towards the possibility of a complete rebuild and all the additional benefits that would come with that.
How to execute the rebuild was the bigger question. The product was an authoring framework for highly immersive, gamified e-learning and users of the product were learning designers and developers. The product was the engine of a very successful content creation business, and the developers themselves were constantly engaged in using the product to create beautiful learning experiences for customers. We couldn’t just stop doing client work while doing the rebuild, as these clients were paying the bills!
Long story short, the business case to rebuild the product was extended to seek funds for an additional senior developer to lead the rebuild effort over 6 months, training the existing developers up as they went. We needed someone who could steer architectural discussions, gain consensus on the approach, do a large part of the coding and bring everyone along on the journey. A talented ex-colleague who had led an authoring tool build at a previous company I had worked at was available. Perfect timing!
Embarking on the rebuild journey
A lot of tough conversations and one business case approval later, we started the job of completely rebuilding the product from the ground up. The new product would have some really cool differentiators that separated it from the competition and would be central to the content team’s business model. There was a lot of excitement among the developers about what it would allow us to create for customers.
One of the key decisions to make was around backwards compatibility. There were hundreds of customer courses created using the old version of the tool, and we had to have a maintenance path for that old content for when customers wanted changes. However the scale of the re-architecture in v2 was so great that this just wasn’t a possibility. Therefore old courses would have to be maintained with v1. The volume of these jobs was pretty low so it wasn’t the end of the world, and a clean break from the v1 architecture opened up a whole new world of creative possibilities for the learning content team.
Towards the finish line
It took over 6 months to rebuild the product. It wasn’t easy but it got done. We actually started building live client projects with it while it was in development, and those customer funds helped us stretch the capabilities of the tool even further. The very first project built was a gamified, immersive environment in which characters moved around to perform Information Security challenges, nothing like the crappy ‘Click Next’ e-learning experiences our competitors were creating with their own in-house tools! It wasn’t VR levels of immersive but was about as far as you could take a desktop learning experience created by gaming afficionados.
Building while working for actual customers could have been a recipe for disaster but the calculated judgement worked pretty well. We were flying by the seat of our pants but the other developers and the wider design team were able to learn about and influence the products capabilities while it was being actively developed, which was a real benefit.
Eventually the teams started building and delivering kickass, high-end digital learning using the new product. And to the best of my knowledge, they are still doing so to this day.
A bittersweet victory
The original working title for this post was: “It’s the end of the world as we know it — What to do when the company wants to keep your product going but sacks the product team“. Because no sooner was the rebuild completed, our parent company restructured the division and made all the product developers redundant. They had put their heart and souls into the rebuild, and only got to realise the dream of pushing it to its capabilities on a small number of projects. A brave effort was made to put forward a business case to save the product team but it wasn’t to be, the team were made redundant and all future development work using this framework was offshored.