When it comes to software development, there is a phrase from business which says “Done is better than perfect”.

I think it takes a while to really understand what this means and how to really apply it in your company. And I'm certain this applies in other industries or departments as well.

Therefore, while it is something that I agree with, for software development and productm I would probably adjust it a little:

Deployed is better than perfect

This aligns much better with the way a team works together to create a good product.

There are some other prerequisites. For instance, deploying also means that what you created also needs to go through an automated pipeline of checks.

If you don't have that pipeline well… you might end up deploying something broken many times.

All right, so back to… how can applying this idea make things worse? There are 2 main ways that I can think of right now.

First, many people interpret this as a permission to do a sloppy job. This is not the case. It should not affect the quality of what you deliver to your customer. (A)

Then, the business might think that OK, we released this, it is “done”, now we can move on to the next thing immediately. Again, not the case. It shouldn't mean creating a feature factory. (B)

OK Vladi, but I don't get, you say. If it should not impact the quality, if I don't create more of these “things” then what is the point? Isn't it the same?

Glad you asked. Now picture a cake. An entire cake for your 50th birthday, let's say. The cake is the idea you have. The feature you are thinking of creating for your customers.

Done is better than perfect means that you won't work on the cake for 6 months or 2 years and then deliver the cake and let people taste it.

It means that you will take a slice of the cake and deliver that slice!

And another thing: By slice, this means a vertical slice. Not a horizontal one. You don't want to deliver the sponge, empty, with no cream from the top or from the bottom.

And that slice is done with good quality in mind. Making a slice takes way less time than an entire cake in software. (A)

Now, the business has even more power. It can decide how big of a slice to invest in. The bigger the slice, the larger the investment (time and money at least). So if you are not confident enough of the feature, you can reduce the investment.

The trick, the part where it sometimes feels more like an art than science, is knowing what slice to make.

Let's take this further. You created a slice. Now what? (B) Now it's time to listen and get feedback. Usually you end up in one of these situations:

• the slice is bad. Everything about it doesn't work for the customer. So you throw away the slice and think about another cake (aka you pivot);

• The slice is OK but could be improved and customers are looking forward to your cake. You adjust and server another slice. Continue until the feedback is good enough, and you learned enough and have the confidence that you can deliver an entire cake, the right one, and it will be well received.

• The slice is OK, but customers don't really need an entire cake. That slice and maybe another one is enough. You don't spend any more resource on this, so then you can focus on other things.

Phew, that's a bit long, isn't it? Well, here's another shorter version: Making the slice and serving it doesn't end there. You require maintenance for that. And it all adds up pretty quickly for each slice you served.

I could continue ranting about those 3 situations I mentioned earlier. A lot. And continue with this analogy for a long time. But it makes me hungry for a cake, and I would probably lose you along the way.

It's not easy. But that's why you can hire people like me. To help with this kind of stuff.