It’s time to name and shame a behavior that costs our economy billions each year, wastes most big businesses’ precious resources, and makes our jobs in software development just that little bit more miserable and conflict ridden. I call it hoarding.
Last year, I was driving along with my two daughters in the back of our car. Ash, the eldest, then nine, started telling six-year-old Alice about how bees pollinate flowers when they make honey and how that caused food to grow and how without bees the world would run out of food (and honey) and we’d probably all die.
Alice nodded all the way through Ash’s explanation, made a thoughtful face at the end, then said, “I’d probably die without potatoes.”
Alice loves potatoes—especially roasted ones.
Once, a couple of years ago, we ran out of potatoes at the end of a meal and wee Alice—who is, honestly, the cutest thing you’ve ever seen—was grumpy for the rest of the day.
Nowadays, Alice attempts to hoard spuds at the start of the meal, just in case. As soon as my wife puts the dish of spuds out on the table, Alice grabs as many as she can, loading her plate high up. Why? She's afraid that if she doesn't, there'll be none left later on and she will miss out. It's the tragedy of the commons in miniature, and it wouldn't happen if Alice didn't perceive a scarcity of spuds. If we cooked 200 spuds for our family of four, then there'd be no need for her to hoard. But we don’t, so she hoards, which encourages the rest of the family to hoard, lest we miss out; we often end up throwing out a few of the hoarded potatoes.
Hoarding, generally speaking, happens whenever there is competition for a valued and scarce resource. You see hoarding before and after natural disasters when people dash to the supermarkets and empty the shelves, selfishly—but understandably—grabbing as much food as they can for fear that they’ll starve. Big manufacturers, on the other hand, competitively hoard components and raw materials they speculate will be scarce in the future.
Likewise, hoarding is an incredibly common—but usually unnamed and invisible—phenomenon in corporate software development. Our customer's hoard scarce IT time by loading as many features into their requirements document as they possibly can, even though many of the requirements are of questionable value. Their reasoning is understandable. They may think something like this: “If we don’t ask for feature X now, and we find out later on that we need it, then we’re out of luck.” The customer knows they’ve waited two years for their project to get to the top of the software development queue. They know that once their project finishes, they'll not receive any more IT resources to work on feature X for a long, long time—if ever. So, just like my Alice, customers hoard their metaphoric spuds.
This resulted in requirements documents being loaded with low value containing a lot of “we might want it one day in the future, but we might not” features. The product is much bigger to build than it needs to be, it’s more challenging and considerably more time consuming to test, and the projects take considerably longer to deliver. Financially speaking, it costs more to deliver and the project’s financial benefits, which are only earned by shipping, are delayed, as are the start and end of the next big project.