There are no quick wins... unless...
Quick wins with legacy code in a legacy organization is a fantasy that too many people ask for and too many people promise to deliver. The narrative goes in one of three ways: from a blunt “can we have a quick win?”, to a more subtle “wouldn’t it be possible to?..”, to a stimulating “how difficult would it be to?..”. These are benign questions in their intent, and in many cases are screams for help. It’s hard not to feel sympathetic towards people who are befuddled by a high cost of what any reasonable person would agree to be nothing more than a quick win. People in roles capable of delivering the ostensible quick wins are reasonable people in most cases, and they’re compelled to make promises they often struggle to keep.
I’m convinced that quick wins with legacy code in a legacy organization is a fantasy. One analogy that comes to mind is a large and fully loaded cargo ship that tries to navigate between numerous islands to pick up bananas from the trees.
The ship is already in the ocean, the islands are close, bananas are ripen and are ready to be harvested – everything appears to be lined up for quick wins. Everything, except for the most constrained details. The captain is incentivized to sail the ship directly to the destination port on time and without exposing the ship to unnecessary risks. The ship itself has a strong momentum due to its own size and cargo weight that resists any sudden itinerary changes. It is still possible to visit the islands but at the expense of failing to arrive to the destination on time, and quite possibly loosing some containers while making the turns. The quick wins can quickly turn into quick losses.
The same dynamics are at play in a legacy organization with a legacy code. The legacy organization sets the itinerary for the next 12 to 24 months and any deviation is not without a substantial administrative and process costs. The legacy code has accumulated so much weight, metaphorically if you will, that making changes outside of system’s main purpose can make other sub-systems behave unpredictably – similar to the cargo ship dropping containers on sharp turns.
There are two ways, as far as I can see, to deal with this dilemma in a productive way. First, to buy another ship to share the weight if the cargo being transported could be profitable enough Second, to unload the cargo to reduce the weight. The choice is driven by a particular organizational situation, and either choice is better than a pernicious status quo: pretending that the organization is sailing on a half loaded ship, always ready to load more containers and easily adjust the itinerary for quick wins. While waiting to buy another ship could be a distant possibility, the proactive unloading of the cargo ship ought to be an essential function of engineering and product managers. Seeking out and retiring products and services that do not produce as much value as originally estimated is a prerequisite for an organization striving to scale and seize new opportunities. It doesn’t always have to be to a degree of Google sunsetting Google Reader, for example. Any small process or product that takes a disproportional time to maintain as compared to realized benefits is a worthy target. Leaders must perform the evaluation of such targets at the same level of organizational visibility and support as introduction of new features. Going back to the analogy, once the decrepit and rarely used containers are unloaded from the ship, the more chances it has to visit unplanned islands and gain opportunistic benefits.