I was having lunch with some friends and other business owners and developers yesterday, and one of the topics that came up during our discussion was the idea of how good is good enough?
Specifically, whenever you’re working on a software project, when is it Good Enough™ to ship to the customer?
The implication being, of course, that if it’s good enough then it satisfies the requirements, but there’s likely some underlying tension that, given more time, money, or some other resource, we would go back and improve certain aspects of a project.
If you’re a developer or a designer, perhaps you’ve felt this tension. I have. For what it’s worth, I feel it with nearly every single project I on which I work.
And sure, we can debate all day long what it means to be good enough. But I think that the definition changes the further we get into the industry.
How Good Is Good Enough, Anyway?
The point I’m trying to make is that good enough is a moving target often dictated by your level of experience (versus any other qualifier like, say, your age).
I assume, for this post, that you’ve been in the industry long enough and working with a similar set of tools and languages to fully grasp the idiosyncrasies of each of the languages and tools you’re using. I’m not shy about my preference on going deep rather than wide when it comes to building software.
It Changes Over Time
At the same time, the level of experience what we consider “good enough” moves. When you’re first starting out, good enough is likely just getting something working. If you’re on a team – especially of experienced developers – you’re likely to get a lot of feedback on how to improve things.
And at first, this can be challenging. Perhaps it’s even a bit disheartening. I mean, you’re proud of what you’ve done but then you have a handful of people telling you how to change things. The same thing happens in open-source, by the way (for whatever that’s worth).
Not to sugarcoat or change anything because you’re right: It can become disheartening. I mean, you’ve spent who knows how many hours working on something, you get it working, and then you have your peers correct a lot of the work you’ve done.
Remember that the motivation behind said critique has nothing to do with you as a person, though. And it has nothing to do with saying you aren’t good enough. It’s saying that you’ve got it working, which is great, now let’s make this even better.
As you learn more, suddenly the measurement of what was once good enough changes.
When What Once Was Good Is No Longer True
And this is where the tension comes into play: What once was good enough is now no longer good enough. It’s subpar, right? So the new good enough is something more organized, better architected, and better organized.
Then a new tension is introduced: You hit a deadline, or you run out of money, and it’s time to ship the product. You know that the work you’ve done is good, manageable, and documented well enough to maintain the project moving forward.
But it’s not good enough because you’re aware of the things you could optimizing if you just had a little more time. You don’t, though – you gotta ship it in its current state.
Here’s the dirty little secret in the industry that, for whatever reason, people don’t want to admit: It’s okay to ship it in that state.
Shipping the product in its given state is okay.
First, the state in which it’s in is not only better than nothing at all; it’s something that’s better than what you used to be able to do.Those of us who care about this craft feel this with nearly everything they
Secondly, software is malleable. It can, and will, be changed over time. That’s why we have versions of our work. Those of us who care about this craft feel this tension with nearly everything we do.
Finally, the idea of what’s considered Good Enough™ doesn’t go away. It just moves. The more you learn about producing good software, the difference of the definition of what’s good enough changes.
The Tension Doesn’t Resolve
So get used to the tension. Embrace it even. If you’re not feeling it, then I’d argue you’re not concerned with producing a quality product. And I know that’s a bold statement to say, but I’ve yet to meet a developer with her or his merit who doesn’t wrestle with it.
It’s part of the job. Take it for what it is. If you feel it, that’s a good sign that you’re on the right track.