The Fallow Field Theory
Legacy software migrations are complex and risky. In the era of agile development, why do we continue large rewrites of code?
In the digital media space there are a lot of site redesigns, which are invariably more than just in place visual design changes but feature changes as well. Most of the time developers will use a redesign to eliminate (or so they think) technical debt by doing it the right way this time. Instead of getting their existing code to meet the desired design changes they rewrite everything.
Today you can see some of the risks associated with this practice at hbr.org. Before I go any further I should state that development teams that I have led have rewritten code from scratch with similar peril. The question is why do we do something that is so dangerous?
Fundamentally, Julian’s point was that 1) trunk will continue to be updated during the redesign of any code and therefore you are duplicating efforts to create feature improvements for both the legacy and new code base and 2) the minimally viable product is the exiting product. The latter of these points is the one that I am fascinated by.
A minimally viable product or MVP is the minimal portfolio of features that the user will expect to use the product. It is rare that any customer base is willing to let go of functionality. If designed properly (and that is a huge caveat) then all of the features should have been created to meet some consumer demand. Therefore, Julian’s logic is that the MVP will be the existing site’s functionality.
This simple insight outlines the problem perfectly. A redesign should only be design refactoring and nothing more. Similarly when we refactor code we are not supposed to create new functionality. Why are we changing the functionality to match the time of the design change. Inherently this is because we still tie the concept of visual design and UX. I should be able to change the visual design of a site without changing the underlying functionality.
The issue arises when the redesign needs to be justified. Why change the design of the site? Because it will allow us to change the functionality of the site to increase revenue, audience, or whatever metric you please. If the visual design had to stand alone it would never get done. However, if the code refactoring had to stand alone it would never get approved either.
We need a new path forward. As much as we focus on technical debt, we need to concern ourselves with design debt, and UX debt. Designers are still stuck in a world largely driven by the outdated model of set it and forget it. They spend a lot of time up front building style guides and then they keep MacGyvering this style to fit desired functionality. Eventually, the style guide is either so outdated, design turnover becomes too high or the style guide becomes too great an obstacle to accommodate the customers’ needs. And the redesign is born.
I would like to propose a three field system to address the issue of debt for the tech, UX, and design teams. In short, the three field system refers to a medieval solution to guaranteeing better crop yields over time. By rotating the crops through three fields, one of which is fallow while the other two are active, the fertility of the soil was maintained. In turn this produced better crops which improved the overall nutrition of the consuming population.
