Once, I was working on a project to revamp the billing services for the startup I was working at. The project felt more like archaeology than development. There were folks at the company who were aware of the billing codebase, but nobody, not even the folks whose names were on the commits could tell me anything about it. It was as if the previous developers, upon completion of the project, said a few thoughtful words, lit the thing on fire, and pushed it out to sea. They shipped it like a Viking funeral.
Years later it fell to me to extend and improve the system, and to do so, I had to pick up those charred remnants, ponder how they might have once fit together, and attempt to reassemble them back into some kind of seaworthy vessel. There was no documentation about what the code was intended to do, about why it was structured the way it was. The maintenance on the system, such as it was, was extremely tactical – as though maintainers were afraid that disturbing the sediment around the rotting timbers would accelerate its decay. At the end of the day, it was better (as it inevitably proves to be) to keep what was there and extend it, but coming back to a project that was left for dead is certainly one of the hardest ways to earn your pay in engineering.
In the years since, I’ve found myself on both sides of this story a few more times, both coming back to projects or areas of the product that had been cast away, and knowingly and sometimes even willingly being a part of the team that knew we were giving a feature its hopefully final send off. This has perhaps given me some insight into why it happens, why you might even what to do it, the drawbacks, both obvious and subtle, and some strategies for minimizing the wreckage.
First, it’s worth being clear about why it sucks to ship something and then completely move on. To me, the most obvious harm is the loss of context and understanding. Even if the engineers who worked on a project are still around, the fidelity of their memory will fall off dramatically if they never look at the code. Plus, they are working on something else now – the rewards, both internal and external, are lower for looking back at something you hoped to never see again than for working on the new exciting project in front of you. Most folks I’ve worked with would enjoy working on something fresh, completing the work they know they will be measured against, rather than trying to find the subtle bug in code they checked in three years ago.
Redeploying a team the moment they deliver their MVP is also a great way to minimize velocity and maximize ramp-up time. The vast majority of time spent on a project is not in writing the code itself, it’s in building the context, learning the domain, validating and defending architectural decisions. When a team is reallocated, or disbanded, this is the effort that is lost and must be rebuilt in order to make progress again later.
The last major harm in moving on so decisively at the culmination of a project is that the team does not enjoy the consequences of their work. A team that will maintain their work indefinitely is a team that will invest in making that work easy to maintain. Allowing a team to constantly leave their mistakes behind them, combined with pressure to constantly deliver quickly in new spaces leads to engineers or even entire teams that carve a path of destruction through the codebase, writing a ton of poor quality code very quickly. Conversely, allowing teams to maintain and extend their own delivered code has the combined effect of incentivizing good output, and slowing down the teams that produce the worst quality, limiting the extent of the damage from bad output.
With so many problematic impacts, why are so many organizations keen to “Ship it” and move on? One major cause that I have seen, is a vicious cycle that derives from the cost of ramp-up and from the shared understanding that when the project is done, it’s done. The longer a project goes on, the more of a backlog builds up behind it. Layers of management become increasingly agitated about the slow pace of development, and increasingly enthusiastic about the Next Great Thing. The enthusiasm to move on slows the project down by making it hard to cut scope. Once it is clear that the project will conclude when it ships, there is suddenly great motivation to cram in every last possible feature – we can’t ship it next time because there will never be a next time.
Once the project ships, the team moves into a new area, possibly greenfield, but more likely some other area that had been neglected while the previous project dragged on. In either case, the team is returned once again to a slow crawl while they rebuild enough understanding to become effective. This slow pace then sets the conditions for another iteration of the cycle.
The challenge for an engineer, manager or or even a middle manager who is responsible for a project that is subject to these pressures is how to break the cycle. The technique I’ve found effective, beyond merely explaining the issue and advocating for change, is to find and promote projects that feel to the business like “moving on” while allowing the team to build on the same technical foundation that was already learned and proven out. Finding ways where the technology your team has already been building can support new customers, or provide a new press release can keep your team efficient and focused, while still meeting the business’s craving for novelty.
There is one time when it’s good and proper to ship something and never look back. From time to time, you will be asked to write a feature to just check a box. It doesn’t make the product better, and the work doesn’t take you in a direction that you want to go, but for some reason, it just needs to get done. Back in the early days of Microsoft Word, Microsoft was trying to woo the journalist and author Jerry Pournelle, an influential early adopter of word processors. The feature that was needed to finally seal the deal was the “Blue background, white text” option added to Word 3.0, meant to make Microsoft Word look just a bit more like Word Perfect running on DOS. That feature stayed there, untouched, tucked into an obscure menu until office 2007.
Sometimes the need to check the box is there, but the use case is so niche it’s not worth the energy to really flesh out or support the feature in the long run. That is the time, in my opinion, to scope it tightly, get it done quickly, take it to the beach late in the evening, and Ship It into the setting sun.
Leave a Reply