When adding new features to a software product, we tend to plan them by the value they bring versus the cost of development. However, it’s critical to consider that they also come with a maintenance price tag attached to them. Ignoring this cost, can affect the user experience, cause a system crash and/or make it harder to do any changes in the codebase.
In an ideal world. We’d pay for the cost of developing a feature, but once it’s out, we’d never have to spend more resources on it. And while there might be a few software products out there, that run with minimal maintenance, we should not assume this will be our lucky fate. Yet, product and development teams alike, seem to think this is the case.
Because of this misconception of pay once, enjoy forever, we constantly fail to evaluate the costs of maintenance of a product before we even start coding it and only address them when something is broken. We are even willing to cut corners deliberately to ship sooner because we believe that first to market wins the race every single time. And everyone starts noticing the problems:
- Customers, experience a slow and buggy product.
- Developers, have a hard time understanding and changing code.
- Product, has to cut down features or cancel their development because the velocity of the team is too bad.
Instead of addressing the problems, more corners are cut, and eventually, it becomes a habit and the only way you do things. By the time you realize, you have dug your own grave and, soon enough, start talking about full-refactorings. Paying some tech-debt is hardly ever an option. Developers are blamed for building such monstrosity, but product and business were right there at the co-pilot seat too.
To avoid this situation, product and developers must work together to make maintenance part of the development process. The product team should, at the very least, have healthy buffers during units of work, so developers can address maintenance, but ideally understand it well enough, so they can be the ones planning for it. And the development team shouldn’t work without thinking of the maintenance impact of their code, and own their solutions all the way to production.
The most important thing to understand is that, doing maintenance proactively, is always cheaper than having to react. And while fully getting rid of emergencies is not possible, reducing the amount of them will give you more time for feature work and will keep the stress levels of the team under control.
