When ‘Good Enough’ Isn’t Good Or Enough

You know the phrase “good enough”? As in, “it’s good enough right now, we can worry about fixing it in the future”? Well, when it comes to software development, I really hate that phrase. Let me explain why. 

Simply, it’s because the concept of ‘good enough’ isn’t true. It’s the best type of paradox. Something is either good or it’s holding you back. There’s no in-between, especially when it comes to the state of your technology and your R&D team. Therefore, saying that your team – or your product – is ‘good enough’? That means that they aren’t. Because either they’re good or you can do something to make them better.

What does tech debt have to do with it?

Before we delve into the specifics of how to achieve the ‘better’, let’s take a quick look at what tech debt is and what it means in a tech company. According to Andrew Smith, “Technical debt or code debt is a metaphor that refers to all consequences that arise due to poorly written code and compromises in the development. This concept, in particular, includes the extra effort that has to be done to improve the software or to add additional functionality.”

Let’s be honest with ourselves. We’ve all looked at our teams and thought “hey, things are fine as they are – why fix what isn’t broken?”. And yet, if you really think about it, they’re all taking time, effort, and resources. And if something isn’t broken, it still doesn’t mean that it’s working as it should. And even more so, it doesn’t mean that it’s not affecting performance, velocity, and productivity. Quite the opposite- it most likely is.

Technical debt takes time. It pushes off other tasks, features, or whatever else that you wanted to do. And the worst part? You can work on it for weeks – or even months – and at the end of the day still have nothing to show for it. So if you don’t really need to do it – and you can get by perfectly well (at least you think so) by not doing it- well, why fix it? The customer almost never sees it. Almost no one but the R&D team knows about it. Who will ever know?

Ultimately, you and everyone else will. It can look like a waste of time to have to spend energy on taking care of, but I assure you that it’s not. If by resolving it you take five minutes off of every workday for your developers, it looks like nothing. But if you look at it over a greater period of time, that’s a significant amount of time saved (not to mention the resources invested in that time). And it’s not just the time saving, but also speeding up processes, smoothing out workflows, and saving significant resources.

Be ‘good’ and not just ‘enough’

As a tech company, the goal is always growth: a better product, more (and cooler) features, more customers, better revenue, and on and on. However, growth often comes with a price. And that price is maintaining a state of being ‘good enough’. 

The more you grow, the more that being ‘good enough’ takes out of your team’s efforts, their tasks, and ultimately their motivation. Let’s say for instance that you’re a company of one developer. With tech debt, it will take that single developer a bit more time to accomplish what he needs to. But what if you were a team of 20 developers with tech debt? It means that everyone will have to work around it to accomplish what they need to, which will eventually end up costing you days – at the very minimum – from your R&D plan. Bottom line: the more you continue to work around your existing tech debt, the more tech debt you’re going to generate, and so on and so forth, until you’re drowning in tech debt and can’t find your way out. 

Going beyond the good

Dealing with your tech debt –  and propelling yourself beyond the lame excuse of ‘we’re really good enough now’ – shouldn’t be an overwhelming endeavor. Begin by:

• Looking into what takes the most time in your team. You need to filter whatever isn’t tech debt and what is holding you back. 
• Understand what needs to be solved first and what has dependencies. Prioritize accordingly.
• Find the time to actually do it. 

That third step is the hardest. We’ve all been there- features need to be made, customers have demands, and the list goes on. Finding the time to take care of it and optimize and fix it will be difficult. But it’s not impossible. Define a percentage of the work in your roadmap for tech debt (like we do here at Rookout) or try adding the tech debt into roadmap tasks. If those don’t work for you- here are a few ideas on how to minimize waste in your R&D. 

Striving for greatness

If you find yourself using the statement ‘we’re good enough as we are’, it’s time to take a second look and reassess. 

Are the tools and processes that you have in place really helping your team? Or are they holding them back? Adding tools and processes into your devs’ workflows should be done to make their lives easier and more efficient, not to create more things that they are unable to maintain. One way of doing that is with a live debugging tool that enables them to collect any type of data on the fly with no extra coding, redeployments, or restarts. So yes, you could claim that your developers are good enough without a live debugging tool. They could step-by-step debug, write endless log lines, or wade through the murky waters of lacking the necessary data to understand their code. But why have them be ‘good enough’ when they can be great?

So go ahead. Fix it. Reassess the rest of the tech debt. Then repeat the process. It’s never enough- but doing the most you can to optimize everything you can will elevate you and your team from ‘good enough’ to great. And isn’t that where we all want to be?