Always Be Shipping
Introduction
Sometimes when I’m advising startups the topic of a feature freeze comes up in a variety of contexts. The context I’m referring to is one in which technical debt, poor architecture decisions, and other related issues, have accumulated in a system to the point that it has become seemingly unmanageable. The situation has allegedly become so dire that all new development of features for the business must stop in order to dedicate all developer time and energy to cleaning up the mess. This cleaning up process, which the technical staff often referred to as refactoring, is claimed to require so much effort that no other work can take place.
The feature freeze, in this context, is the equivalent of declaring technological bankruptcy. However, unlike a situation where bankruptcy is declared and an entity is able to renegotiate obligations in order to become stronger, this form of technical bankruptcy almost always leaves the technical leadership with less political capital than they had when they started, not to mention the resulting non-existent level of trust from the business.
A feature freeze is a bad idea. It doesn’t address the root problem of doing development for the business alongside maintenance work for the systems. It gives the wrong impression of priorities for the business. For yourself as a technology leader, it creates a deep political hole for you to dig yourself out of.
Therefore, you should always be shipping. You should always be shipping code, features, services, and every metric of value you deliver to the business. There may be times when more valuable output is produced, and times when the output lessens, but you must Always Be Shipping!
Liar liar pants on fire
Usually when a technology group tries to make the case to the business for a freeze on new feature development so they can work on system maintenance, they hold that it’s simply not practical to continue developing on the current system. This is almost always a lie, and the business knows it. At the very least, if it isn’t a conscious lie, it calls into question the judgment and competence of the technology leader advocating for the feature freeze.
The reasoning is pretty straightforward. In theory, if you left the system alone, it could probably keep doing more or less what it’s doing right now with only minimal maintenance. With that in mind, any additional work on the system has to be split between grooming the current system to make it more maintainable and extensible, or developing new features. If it is literally impossible to develop new features on the system, it would probably also be impossible to continue operating it since that would mean that 100% of developer time is currently allocated to maintenance alone. While this can happen, it is extremely rare, by definition, in products and systems recently developed. They simply haven’t reached a stage of maturity where maintenance becomes the primary focus or concern.
Therefore, if you say that no new feature development can take place, chances are that you’re lying, or at the very least, giving people the impression that you aren’t sufficiently competent to be leading the engineering efforts in your organization.
Instead of claiming that additional features cannot be developed due to maintenance burdens meeting or exceeding 100% of development capacity, which is probably not the case, it would be more advantageous to manage the relationship between your team and the business. Make it clear to the business that there are times when the team will have higher output, and times when it will have lower output, but progress towards shipping things to customers will always move forward.
Fun note: This is the team-level version of developing a lock-free algorithm since, although some things might take longer than others, progress is always made. When you’re designing your software development process as an organization, think about it like a lock-free algorithm.
Perception is reality
A feature freeze negatively affects the relationship between the technical teams and the business teams of an organization. During the period in which no business-relevant output is forthcoming from the technology organization, the rest of the business will grow increasingly hostile toward, and will continually question the value provided by, the technology group. This makes sense because, after all, technical naval-gazing does not generally provide value to the customers and therefore the business.
This perception builds, and the technology leadership keeps defending the lack of features in favor of systems improvement. However, the situation quickly reaches a point where no amount of systems improvement can undo the perception from the business that the technology group just isn’t very productive or useful. That’s a very bad political and cultural situation indeed.
This becomes even more problematic when we consider the effect of things like the availability heuristic as a cognitive bias. This means that people place irrationally high value on recent information when reaching their conclusions, and if the recent information they have in their brain is that the technology team doesn’t produce very much output for the business, then that perception is their reality.
What you did for the business a year ago matters little. What have you done for the business lately?
Care and feeding of a technology platform
Paying off technical debt and keeping things in good order is a result of a culture of responsibility and good development practices. It is not in any way a result of some singular effort to improve things.
Think of your codebase, platform, module, etc. as a garden. Gardens require constant attention in order to function optimally. Weeds have to be removed, seeds planted, crops harvested, and flora and fauna relocated. Because this happens continuously, it is completely unreasonable to expect, for example, that you can remove weeds from the garden once and they will never return. Nobody expects that. It’s just preposterous.
Likewise, a codebase is always becoming more chaotic. I am absolutely convinced that the Second Law of Thermodynamics applies to software projects. The entropy of a codebase never decreases! If you do not invest your energy in keeping the code high-quality, it will devolve into chaos that is progressively more difficult to maintain.
Since this maintenance requires a process, doing a feature freeze to clean up your systems does not fix the actual problem. Instead, it’s necessary to redesign your development process, set expectations, and communicate responsibilities. Developers, team leads, and architects must understand that they must continuously make small improvements to the platform and perform maintenance efforts. It isn’t something you can do all at once, so it doesn’t make sense to try to fix it all at once.
What do?
So what should we do in a situation where we have a mass of things to fix in the codebase, and a huge backlog of product features to build?
First, take a good look in the mirror and fix the cultural and process deficiencies that allowed this situation to develop and become problematic in the first place. If people aren’t writing quality code, if the test coverage is insufficient, if code reviews aren’t taking place, all of those cultural and process-related problems must first be addressed. This step does not, in any way, require a freeze on new feature development. There is no need to inconvenience the business to make this happen.
Second, use these cultural and process changes to produce higher quality code not just for the features currently in development, but also to generally improve the future quality of your team’s output. Add another step to a developer’s work wherein they improve a test, or refactor a module or class, or do some other small thing that measurably improves the quality of the code. This step would not require a feature freeze or inconvenience the business, either.
Just keep improving things as you go. Fix the process deficiencies and make developers aware that higher quality output is expected and required.
What NOT to do
Do not do a complete and one-shot rewrite of any system. This is almost always a bad idea, it’s a nuclear option, and I can’t recall ever having seen it succeed with any established system. If you want to rebuild parts of the system in the process of implementing the cultural and process changes mentioned above, that can work very well (and it’s what I typically recommend). Definitely don’t go the route of trying to do a feature freeze in order to do a system rewrite. It’s the worst possible path for all involved.
Most importantly, do not negotiate feature vs. maintenance development effort percentages! It is not advantageous to have this topic come up as a result of touting the new process and culture of the development team to the business. In fact, you should not discuss your team’s new process and culture with the business as some kind of selling point. Doing so will only result in the question of how much time you are spending on these new quality efforts compared to feature development. No matter how much time you report, the business will want you to lower it.
The business doesn’t understand that time spent on maintenance is not wasted time, it is invested time. To them, you are simply taking time away from developing features, and features are what attract and retain customers. From their perspective, you are moving feature development time that pays off now, to platform investment time which might pay off in the future in some sort of ambiguous way they cannot quantify. The logic isn’t incorrect, but it is an oversimplification. I’ve never seen a business organization that really understands the value of higher quality code. In almost every case, even if the leaders of the business support efforts to improve code quality, the product owners, scrum masters, or other project whip-crackers will always try to get you to sacrifice quality in order to ship faster. Quality is your responsibility, because the business types don’t get rewarded when quality is high nor punished when it is low. They get recognized and achieve advancement by shipping things, and the quality issues usually don’t turn up until later. As a technologist, that means you’ll be holding the bag for low-quality software what was shipped quickly.
Therefore, avoid rolling out the above changes to culture and process as though they’re some kind of new initiative from technology leadership. Without any kind of grand announcement, the business will start to benefit from faster development speed and lower maintenance issues as the code quality gradually improves. If you try to tout these initiatives, they will, perhaps paradoxically, be more likely to fail. Just do the right thing without trying to obtain credit or to use the efforts as a buffer or excuse for not delivering as quickly as the business wants. Down that path lies much pain.
Conclusion
More than the fact that it isn’t necessary to stop shipping in order to do maintenance work, it’s outright detrimental to your system, team, perception as a leader, and your relationship with the business organization. Instead, adopt a process and culture of continuous improvement while continuously shipping, and you’ll be supporting the business as well as your team with sustainable, long-term strategies.
Just as with a fruitful garden, your processes and systems require a measured but consistent amount of care and upkeep. Make that upkeep is one focus of your team’s efforts rather than bulldozing the garden in a misguided attempt to not spend future time on maintenance. Not spending time on maintenance is, after all, what got you considering a feature freeze in the first place.