Technical debt is well-trodden ground in modern discussions of design and development. So-called “software rot” can damage team productivity and make every bug fix and feature addition all the more painful. Less often mentioned are the consequences of the same entropy on the software that supports the software, such as the infrastructure that enables validation and deployment of the product.
Let’s explore this topic using parable of sorts about an ancient society who lived on a small island. They could fend for themselves for short periods of time but at various intervals they inevitably needed to refresh their supplies, trade with their neighbors, and so on. Early in their history, they built a bridge to facilitate this trade route. It took a painfully large initial outpouring of materials and labor, but everyone pitched in knowing it was quite literally a matter of survival.
At first, having any bridge at all was great. They could fill their carts and wagons with yields from the local crops, roll them across the water, and come back with useful minerals and exotic foods. Over time, though, some deficiencies and safety concerns arose — rickety boards and a lack of guardrails were causing slowdowns and injuries. But this was no matter for the island society and its industrious spirit. The bridge was dutifully repaired and retrofitted and all was well for a while longer.
After many generations, the bridge displayed the effects of overuse and overall disrepair. The society was changing rapidly but the bridge was stuck in the past. It was literally crumbling under the weight of the heavy vehicle traffic which was expected to become even heavier over time. To avoid interruption of the bustling trade economy, a few maintenance workers would make periodic off-hours “quick fixes” to keep the bridge passable. But even this light support duty was becoming increasingly more difficult and expensive to pull off — after all, there are only so many times you can bolt on cheap reinforcements before structural integrity becomes a serious issue.
The island society was split into many dissenting groups on what to do about the bridge. Some were indifferent: “As long as the goods continue to reach the island, there is no reason to take drastic action.” Others were in favor of raising funds to support a new bridge project: “With enough time and money, we can produce a state of the art structure that our grandchildren will still marvel at!” Then, a third group emerged with a strange question: “The bridge allowed us to advance to our present state, but is that really what we need to make the next leap forward?”
Intrigued, the other groups listened while members of this third faction expounded on their provocative message. “No one can deny that the bridge is currently essential, and indeed it will be essential to support any future investment we make — we will no doubt need functioning supply routes as we plan and build modern structures. But the engineering breakthroughs happening around us have given us new options; we no longer need to limit our thinking to the old ways of bridges and wagons.
“Across the water, we have begun to see modes of transportation which could transform our lives — large cargo ships, fanciful flying machines. If we invest in infrastructure to support these new technologies, and mix in some of our own ideas, we have the potential to substantially improve our society.”
Not everyone was convinced, but soon enough people converged to form a critical mass of support for the third group’s ideas. Committees came together to study and learn about sea and air transport and began producing fully functional prototypes. All the while, the bridge was maintained to the degree necessary to support the bold and disruptive experiments.
Slowly but surely, traffic over the bridge reduced to a trickle. The prototypes morphed into production-ready ships and airplanes carrying more goods farther and faster than ever before. Of course, this new system was by no means perfect. Occasionally the bridge came in very handy when it was too foggy to travel by air and the boats were in the yard for repairs. Despite these occasional hiccups, the island society was proud of the advancements they made.
The bridge, being an impressive feat of engineering for its time, became a historical attraction which the society looked upon with some reverence and a bit of nostalgia: “Everything we needed once passed through here; how far we have come — and yet how far we still have to go.”
Your parable is not vivid enough and is too wishy-washy like a Sunday school lesson 🙂 It would be useful to explore technical debt in the context of ‘agile’ or services or whatever people say to make them feel better at work. The parable makes it sound like the ‘ok’ thing to do is to just keep on bolting workarounds onto a system until at some future date you have no choice but to drastically change course (perhaps leaving backward compat and other customer expectations in the dust). So is your parable a happy ending or a sad one? Innovation occurred, so yay I suppose; but that probably doesn’t make a great story for the engineers or customers of the bridge for all those decades.
Shipping releases agile-y is great, but only if you realize what that means for your technical debt. I will liken it to wiping your ass (confronting the technical debt) after taking a shit (the release).
Most teams aim for a 10 when they ship*, but most only get to a 7 on some arbitrary scale as far as engineering goes. Sometimes the bathroom is out of toilet paper I suppose, so that’s to be expected. More concerning, however, are the folks who just don’t wipe even when they are given the toilet paper. They’ll continue onwards releasing 7 after 7 after 7** until they, literally, can’t ‘ship’ anymore because their pipeline is, ugh, clogged with massive clumps of shi^W^W technical debt.
At this point, the agility has not lead to a viable platform any longer; and no amount of daily releases will fix it. The system has begun to actively fight back your ‘releases’ and will spew forth unsanitary waste all over the bathroom floors (production servers) from all of your over-indulgent binges.
So ask yourselves, has your team wiped its ass recently? Would you want to work for people who never wiped? Would you be ok wiping after just ever other trip to the bathroom? Would you be ok with wiping along the way? Would you be ok with being asked to come and clean up that mess?
*Unless you’re a “special breed” engineer in which case you aim for a 5 and ship a 2 cuz of the dollar dollar bills yo.
**Hey three 7’s in a row, we must be doing something right!!1
My parable is meant to be general and open-ended enough for you to project your own situations and experiences onto it (positive or negative). I’ll agree that your perspective and chosen metaphors make for much more vivid imagery, though. 😉 Thanks for the comment.