Incremental changes do not provide emergency exits for a failing system. It’s to recognize when a tool is not useful
You want an intro that goes straight for the jugular? Here’s one: Agile methodology’s veneration of small incremental improvements is bullshit.
I am not here to worship waterfalls or eulogize Kanban, and I’m not saying all of Agile’s philosophy is bad — I could even argue that small incremental improvements are not inherently part of its philosophy.
Nonetheless, given the common association, I felt compelled to write this article to help others recognize when they might be riding the wrong horse, or maybe they have unwittingly been participating in a status quo death cult because they can only envision their world moving in painfully slow ways.
It is usually a product, software, or business manager who takes issue with the size or nature of a code change: if your work falls afoul of their assessment of whatever constitutes “small” or “incremental”, then it’s the death knell for your hard work.
So why exactly is this bullshit? Because the gatekeeping is the result of subjective evaluations of non-specific measurements, inconsistently enforced. Let’s look at a couple of examples so you can understand what the scrum I am talking about.
All the objects hurled at an offending pull request are usually completely absent when an app first comes online. In many organizations, new apps are given a free pass and endure virtually no scrutiny from the same gatekeepers who would huff about changes not being small or incremental enough. There was literally nothing, then POOF! Suddenly there’s an entire repository with hundreds of files, functions, and bugs yet-to-be-discovered. Where was the spreadsheet, 3rd-party solution, or some other intermediate step? Where the hell did that skateboard come from? All this to say there are some practical limits to this “small incremental improvements” thing.
Another blindspot is that there is rarely any serious evaluation of an application’s structural quality — it’s just a lot of “LGTM!” from the developers’ own echo chamber. The seeds for failure are sown early on: poor decisions about application boundaries or data modeling can be practically impossible to fix down the line, so if you really want to play the “small incremental improvement” game, then you really need to evaluate new applications very carefully before they come online. Amateur developers make things that work, senior developers make things that scale… and most management can’t tell the difference.
The changes made to our software is guided by feedback, so our code is really only as good as its feedback loops. Wikipedia works very well because it has an open feedback process. Too often, however, our software projects do not. The same gatekeepers who stand in the way of code changes are often controlling what feedback is allowed into the discussion. Business and product folks are focused on features and finances, but your app will suffer if feedback is limited to only these talking points.
Developers, better than anyone else in an organization, can identify software inefficiencies and correct them. Would you rather your product make twice as much money? Or cost half as much to operate? As a consultant and an employee, I have seen many organizations dedicate all their efforts to increase profits but ignore attempts to reduce costs. This may be because improving efficiency isn’t as sexy and it may require making weighty changes to the code. The myopic “solution” is often to throw CPUs or developers at the problem.
In a global marketplace of ideas and solutions, we would do well to remember that efficiency wins. It’s no accident that the lexicon of software development overlaps with that of biological evolution: making small incremental changes is a fundamental and extremely powerful way to drive success. However, it would be overly simplistic to think that your development strategy is justified because it has an analogue in the natural world. Remember that in biology, changes need not be incremental: they can be large and devastatingly fast.
Let’s think for a moment in terms of an invasive species transplanted into a foreign environment whose inhabitants have no natural defenses against the invader’s weaponry. Like an unsuspecting native, your code represents one particular solution, adapted to a particular set of problems. Everything is hunky-dory until you encounter that invasive competitor, and it might represent a superior solution, and small incremental changes do not win that kind of fight.
It’s not always clear who will be the winner when software solutions collide (like pythons and alligators), but the most efficient software with the fewest requirements in terms of hardware or maintainers will have a clear advantage. So your company’s gatekeepers really should listen carefully when the developers try to improve the efficiency of the code, even in cases when thousands of files get changed or when absolutely nothing changes for the customer. You never know when your alligator will have to go head to head with a Burmese Python.
The biggest danger in the “small incremental” cult is that drinking its Kool-Aid can be suicide for your code, your business, or even for the planet. For example, the latest Intergovernmental Panel on Climate Change (IPCC) report states in no uncertain terms that “incremental change is not a viable option” if we are to avoid cataclysmic upheavals with famine, conflict, and disease. Did that report come up in your last sprint retrospective? If incremental change is the only strategy you have to manage your software, let alone problems spanning the entire globe, then we are gonna need to buckle up for the first catastrophe that is predicted for following that dangerously unsustainable status quo.
This happens all the time: a company with “mostly functional” software attempts to transition from scrappy start-up to Respectable Profitability™. Endless man-hours are spent pumping blood through the legacy code while incremental changes are introduced with surgical slowness. Because the existing implementations are so far off from where they should be, it will take years of diligent development to escape the wilderness and arrive at the promised land. But the Titanic can’t turn on a dime, and it is going to hit that iceberg because We don’t have the luxury of time. Instead of saving the project, new changes can introduce more and more debt because there is no incremental way to break out of the flawed paradigms on which it was built. Amidst this madness, the captain dictates that absolutely no man-hours are available for rewriting the system in a way that would avoid the icebergs and sinking ships altogether.
In practical terms, you cannot unboil a frog: you have to make a new one.
With software systems, as with any rehabilitation project, it is far less work to rebuild a new system than it is to perform CPR on the old one. But virtually nobody risks changing the status quo. I fear this sentiment could literally kill us all as dangerous radicals across the globe continue to increase the production of fossil fuels. If software development methodologies offer a window into the future of humankind, then I am filled with fear.
I hope you can see that there is sometimes the need for abrupt and foundational changes in our systems, and that they can be sensible, safe, and correct. I hope this brief discussion gives you a better understanding of how incremental change does not provide emergency exits for a failing system and how important it is to recognize when a tool is not useful. In our endeavors, sometimes we must have the courage to act swiftly when the world is too scared to change. Don’t lock yourself in an incremental box.
I wish that this article was just about software.