Technical Waste

Coders like to code, it’s what they do. They often see the things through the lens of technology as well; What is the best technology for this solution, with little thought given to the actual problem at hand. But that is their job—to use technology to create solutions.

The problems with a solutions/technology first approach to product are well known: specifically creating technically advanced products that no one cares about. Creating web apps that appeal to both everyone and no one.

But another, less obvious problem to this tech-first approach can be both technical waste and technical debt. Technical waste is essentially spending tons of developer hours (aka money) on features that either never get finished, never see the light of day, or are released and quickly abandoned because the design was never fully thought through. It’s a common problem and often seems to happen with younger developers eager to try their hand at something new. Or developers who just want to get something done and out the door without having to go through the various design and approval channels.

Technical debt is similar to other forms of debt. You know you should wait on those new shoes until you get paid, but you have a credit card and it’s burning a hole through your pocket. 5 pairs of shoes, a custom built bike and a trip to Hawaii later, you’re paying more in interest then all the avocado toasts you could possibly eat. Technical debt is the same: a new “minor” request comes through the pipeline, and in order to make it happen, the developer can do 1 of 2 things: code a quick hack to make it happen on time, even though it’s messy and may cause trouble later, or tell the project manager that it’s going to take more time then they thought because they have to refactor a few things to keep the code neat and tidy.

You can imagine what happens in a high speed, high stress situation: hack on top of hack on top of hack, until the software becomes so brittle the team is afraid to touch anything for fear of bringing the whole house of cards crashing down. High turn over can be another factor: there is likely zero documentation of any of these hacks, so system knowledge can be scant. Each new person is just trying to hold the thing together the best they can without poking the bear.

So how do you avoid these common pitfalls? For starters, strong technical leadership and team work can keep tech debt at bay. Actually reviewing code before it gets sent into the world is a good first step, and having a culture of quality over speed. Easier said then done if the business side is screaming for quick turn over. You can do it right, or you can do it fast, but you can’t always have it both ways.

But the solution isn’t just technical leadership, it’s also design leadership. Designers can just as easily be distracted by the newest, coolest thing. Ensuring design solutions are actually tested with real customers is a good first step, rather then riding the wave of assumptions. Real world feedback is the gut check a team needs, especially if they have been trapped in an internal web of self-congratulatory design-thinking.

Once again, this takes time and reflection. Our culture doesn’t seem to appreciate pausing, be that in work or in life. Everyone is always busy, every second scheduled and maximized. Yet getting one’s head of the endless firehose of work and responsibilities is exactly what we need to do to see the full impact of our work. We can’t just pause during a post-mortem, surveying the dust after a clear cut; we need to pause many times through a project and ask: “Does this serve our goal? Our customer? Our user? Our company? Will I be embarrassed by this code in 3 months time? Would I show this code to my mother?” And maybe get up and have a stretch, that doesn’t hurt either.