Business wants features. We want to fix that legacy from 15 years ago that makes you go to your happy place when you open it. An eternal battle of monetary value against sanity and stability. Is there a way to foster both, without making sacrifices?

We have those days full of inspiration. Be that by discovering some new piece of shiny new thingy you want to try out. Or you visited a conference where a guru showed how to use functional programming in a “Hello World” example that now can scale to millions of customers. You are eager. Fuzzy feeling in the belly. You join the planning meeting and express the desire to do some tech debt. And then come those words: But we must deliver this new feature by yesterday. And that thing worked for years, maybe next year. And you reach for that bottle, till it hits you you’re still on the camera.

In all fairness, there is nothing wrong with the mentality above. Yes, it may rub us the wrong way. That is where I think we need to come prepared. Something I was addressing in challenging the status quo. And will be extending during this time. Tech debt and innovation can be translated into business measurements. If you have on-call schedules, number of incidents, and impact on customers. If you care about uptime, start measuring your SLA/SLO/SLIs. Security concerns. Or cost reduction. Numbers never lie. You know about the financial crisis of 2008, right? Anywho, when bad ones star you right in the face, it is hard to ignore them. Let alone postpone them for another decade.

Now that we touch upon it, let us expand. For successful negotiation, data is needed. Based on a couple of examples above, you get an idea of where to start. Backing your statements with facts makes them harder to ignore. Screaming The end is near, is not enough. Use it to negotiate time in the sprint (or whatever illusionary plane of existence you’re working within), and start small. One or two days, when you and a team can work on those improvements. Also maybe, as a bonus, a hackathon every second month. You will know where the limit is. Be flexible and negotiate for the best terms.

Now, we have time. Time to start the work. But where to start? What is the end goal we wish to achieve? Here, I would recommend starting on the first of your days with a small health check. Oh no, he is going agile on us. Hehe, no, no. I am just not sure of a better term to use here. Simply: Define a number of stories you think would provide a nice starting point, as well as visible improvements. After they are completed. That way you can go back to management and say: We managed to provide a value in form of <insert whatever that value is>. The compound effect will push your argument for “time wasted” further. And starting small will also give the team enough time to catch up. And propose their own ideas on what can be improved. Starting with the biggest problem you have, will just end up in a rabbit hole.

Next to the tech debt backlog, consider stories where the team can experiment with Shiny Technology X. That would be really beneficial to the project and not just because of the new and shiny effect. These “open” stories are win-win for me. People will learn new things, and even if the decision is “we are not gonna use it”, no time wasted. You tried and proved to yourself it is not the best fit as it originally seemed. Next to that, will make people engaged. They will be leaving the usual rat race and trying something new and fresh. Out of the comfort zone even. It makes me all tingly even thinking about it. For those stories, I would recommend also keeping them in check and documented by using something like Technology radar. You will also capture the existing state of the system and have a good overview of changes that come into your ecosystem. Or that you’re looking into. Plus easier to explain to new hires what is it that you have. A simple tool, a simple process, a clear picture.

So now that there is an established culture of innovation and tech debt cleanup, time to see how that helps us balance the act of adding new features. All new features coming from business can and should be taken into consideration in your future vision. Of where you see the project evolving. That means putting some adapter pattern or whatever works for you that will “route” it to a new feature.

As an example: During a hackathon team has developed a new version of your service, naturally with a diminished set of capabilities, in the newest version of the framework of your choice. They replicated a feature or two from the existing system and it works as expected. Even better with all the nice benefits you get for non-extra work. Why should that work go wasted? Introduce a feature flag and ask businesses to help you test the new and shiny implementation. This will give them reassurance that everything works as it did and give you a green light to roll it out. With that newly established confidence and management behind your back, all the new features now can be implemented (and existing ones migrated) to a new tech stack. The old system just becomes a reverse proxy of sorts. Yes, it is a bit of extra work in the beginning, maintaining multiple systems in parallel. But no one said it is easy. Suck it up.

Tho, this comes with a set of standards that you should establish. And they all need to solve the problems the old system had. No tests? Tests are now mandatory. No CI/CD? How about we sprinkle some automation on top of it? And on top of those, define some guidelines and establish a basic set of rules. That will push your project to new heights and make it, at least, more enjoyable to work with. Don’t do it just for sake of rewriting it in a new tech stack. Think about how to improve your daily life and the person that comes after you.

💡 Always leave the code you’re editing a little better than you found it. - Robert C. Martin

To summarize: Moving with time doesn’t mean all feature development must stop. It requires some delicate balancing act and it is important for businesses to take this into consideration. The competition that is making the competing product will not make the same mistakes. They will get the hip new team, with the latest new buzzwords in the mix. Innovation will come naturally to them. While you’re stuck, make a sacrifice to that legacy system that “just works even after 20 years”, so you can just change the color of the button. While on the other hand, development teams need to realize that there are bills to be paid. Together with the business, a balance needs to be struck. How much time should we spend on innovation and moving away from the status quo? And how much on feature development?

The points made above, as a bullet point list now:

  1. Create metrics to demonstrate a need for innovation and technical debt cleanup.
  2. Negotiate time within the backlog of work to pick up these tasks. Be flexible, refactoring will not exactly pay the bills, understand that you’re a team.
  3. Add the tech debt and innovation stories to your backlog. They’re not mutually exclusive, both will drive the project forward.
  4. Pick up stories that are quick wins and add value that can be demonstrated. This will remove any skepticism left within the ranks. Don’t start with the biggest problem you have, you’re asking for failure.
  5. Define standards for new features, don’t end up in the same place where you’re now. Just in the shinier new framework. Coding standards, testing, style guides, technology radar, feature flags, etc. Your future self will be grateful.
  6. Keep at it, make it part of the culture. The team will be grateful, and work becomes more fun.

Until next time, try something new.