The Value of Finishing

“The value of the thing is found in finishing the thing.”

This is the advice I like to give about most software engineering projects. You can keep working on something indefinitely to get it just right, but there’s no value provided until you release it and it’s actually in the hands of customers who can use it.

Until that pull request is merged and the code is deployed to production, it’s not real. It’s just an idea.

Something that is released and that is imperfect is more valuable than a thing that’s unreleased and is completely perfect.

Real world examples

Let’s consider some analogies:

There is no value in assembling half of a piece of furniture. It’s not until the furniture is completely assembled that you can use it.

There is no value in putting your clothes in the washer but not the dryer. It’s not until the clothes are both washed and dried that they’re ready to be worn again.

There is no value in cooking a meal but not eating it. Eating and enjoying the food is the point of making the meal.

There is no value in writing a blog post draft but not hitting the Submit button. You could spend your whole life editing and revising your words, but it’s not until your work is published that other people can read it and benefit from it.

The unfinished task provides no value. In fact, the unfinished task is usually just a mess. It’s finishing the task that provides the value. Getting to the end result is the reason you even started the task.

Lessons for software engineering

So what does this idea mean for software engineers?

It means that you should complete work in small chunks that you can release. Don’t release sloppy or unfinished work, but release things that solve real problems and provide real value, even if they don’t solve every problem yet.

It means you should merge and deploy your code often. Avoid long-running feature branches.

It means you shouldn’t let “perfect” become the enemy of the good. Get the thing out there, even if it doesn’t have the perfect API or the perfect design. Again, don’t cut major corners or create an inferior user experience. But learn what’s good enough, and don’t let perfectionism get in the way.

It means that working on a single task and finishing it is better than working on three tasks simultaneously and finishing none of them. The one finished thing brings value. The three unfinished things don’t bring any value yet, because they’re not done.

Please don’t misunderstand

Don't try to take the lesson too far. I'm not advocating for sloppy work, cutting corners, or lowering your standards. I'm also not saying to focus only on the end result or to ignore the lessons you can learn along the way, especially for projects that ultimately get abandoned. Not every adventure we embark on ends up being a success.

But I am advocating for finishing.

The value of the thing is found in finishing the thing.