It doesn’t seem all that long ago when I used to delight in being able to call myself a perfectionist. I was proud of the fact that I could never finish anything because it was never finished until it was perfect. However, 9 years into my career and I am increasingly conscious of the fact that I am still no better at being a finisher. The difference is, I can no longer justify my inability to finish anything on a never ending search for perfection. I am a part of a generation for whom ‘just good enough’ is the end goal.
The Age of Beta
What started as the Gmail Beta has now become standard practice across many industries. In an age where being first matters more than being right, we consider it acceptable to release unfinished applications and software, or to publish unfinished blog posts and articles. We expect 24 hour news networks to deliver credible retrospective analysis on events which are still unfolding as we watch.
It is more important to be first than it is to be right.
Don’t blame the publishers. Collectively we demand to be kept more informed faster than ever before. We demand early access to the next big thing. Who cares, if it is not finished yet? All we demand is that it is ‘just good enough’. We have grown accustomed to watching inane speculation as dramatic world events unfold, reading unfinished articles, and working with incomplete products. Why? We put up with it as a price for early access to tools and information.
For the Twitter generation, even the news networks are not fast enough. By now, we are all too aware that this pace comes at the expense of accuracy. Many a journalist has opined the loss of accuracy in reporting today and so I don’t intend to further that particular debate. But for me we have also lost something else in this rush to be first; we have lost a sense of what it means to finish something. This is true for software development, just as it is true for journalism and publishing.
Release Early and Often
There is a school of thought that says we should release early and release often. Without doubt, this approaches carry a number of benefits.
- Early feedback from your customers/readers
- Validation of a product before significant investment
- First mover advantage
However there is a fine balance between releasing early and releasing prematurely. All too often, the question of when something is actually finished is largely ignored in favour of getting something out there fast. Releasing a product with a carefully selected subset of features that are complete is very different from releasing a product that teases the user with many features, none of which are quite finished.
The distinction may be obvious but it is important. We don’t have to be feature complete to finish something. There is no need to release an article or blog post that is a work in progress. It is possible to complete an article without waiting to see if circumstances change or new events unfold. By all means release early, but release when the article is finished, not before.
Just Good Enough
Releasing early and often should be a concept familiar to those involved in the hip world of start-ups and their associated funding schemes. However it is not just start-ups that are losing the ability to finish anything. We all are, including those of us working in large enterprises. Whether an internal system or a new customer facing product, the goal should always be to finish. At every level from developer, development team, project team or project sponsor it should be clear what it means to be finished. You’d be surprised how often this isn’t clear.
- Developer: Is this code finished when written? When tested? Or when in production? When it performs well?
- Project: Is the release finished when it has features A, B, and C? Or does it need feature D as well?
- Sponsor: Is the project finished when some code makes it through to production? When the first customers use it? When the investment case is realised?
What may also surprise you is that every interested party will have a different definition of what it means to be finished. If no one can agree on what it means to be finished, is it ever possible to finish?
Take any project you are working on now and ask the same question, “When will this be finished?”
Outside of software delivery we can ask similar questions.
- Hacker: Is the hack complete when the you can see how to solve a problem? When you have a proof of concept solution? Or when you have a solution that you are proud to show to others?
- Writer: Is the article finished when drafted? When proof read? When published? When first read by someone else?
- Photographer: Is the picture finished when the shutter closes? When the negative is developed (or edited image saved to disk)? Or when the photograph is framed and hanging on a wall?
- Cook: Is dinner finished when it comes out of the oven? When the last morsel has been consumed? Or when the dishes are washed up and put away?
All to often though, the focus is on “just good enough”. We don’t know what finished means and so we settle for just good enough to move on. As we strive to be first, we have lost the ability to finish anything.
I count myself as one of the biggest offenders. I don’t challenge myself or my team enough with this question, when are we finished? How will we know? Just prior to Christmas I asked a couple of the team at work and was unsurprised to find that they all had different answers.
In Conclusion (Finishing)
The art of ‘just good enough’ is just that, not good enough. As we rush through life, making sacrifices in order to be first (or at least fast), we need to stop and ask ourselves what it means to finish something. When something is finished we have an opportunity to feel pride, an emotion all too often lacking in the workforce of today. But above all, finishing means we can do just that, finish. We can move on to the next thing free from the lingering thoughts and distractions that stem from unfinished work. For me, I’m going to start by finishing this article.
