Done is better than perfect. Careless is not done.

I mostly agree with done is better than perfect.

Perfection has a nasty habit of moving further away the closer you get to it. Improve one thing and you immediately notice three others. Fix those and the first decision starts looking questionable again. In the best case, this slows you down. In the worst, it lets you spend an impressive amount of time executing the wrong idea extremely well.

There is also a psychological advantage to finding out early that an idea was bad. I would rather discover that after a rough first attempt than after weeks of polishing it, defending it and quietly building my hopes around it.

Reality is cheaper when you invite it in early.

The problem is that done is doing a lot of work in that sentence.

What does “done” actually mean?

A surprising amount of work starts without a useful definition of what finished looks like.

When the destination is vague, the route becomes vague too. You fiddle, add things, reconsider decisions, follow interesting detours and keep moving the target because there is no clear reason not to.

It is like setting off on a road trip knowing only that you would like to go “somewhere nice”. You can absolutely start driving, but planning the route, the stops, the time available and even recognising when you have arrived becomes considerably harder.

You do not need a finished product to make the destination clearer. Sometimes a sketch on paper is enough. Sometimes it is a conversation. Sometimes it is a metaphor. I have explained football formations using glasses on a dinner table; the glasses were not sophisticated prototypes, but they were good enough to make everyone look at the same thing.

That is often all a prototype needs to do: make an idea visible enough to argue with.

This is one of the things I like about Eric Ries’ The Lean Startup. The useful part is not the startup mythology around moving fast. It is the much simpler idea that learning should happen before commitment becomes expensive: build something real enough to observe, measure what happens, and let that change what you do next.

Yes I have a copy. The useful bit is the reminder that learning early is usually cheaper than being confidently wrong for longer.

Once the destination becomes visible, planning the journey gets easier.

Sometimes the wrong definition of done looks a lot like progress

January gyms are probably one of the clearest examples.

Someone decides they want to get fit and, within days, owns new shoes, gloves, bottles, supplements, an app subscription, three sets of gym clothes and enough accessories to suggest Olympic selection is imminent.

The shopping list gets completed beautifully.

The problem is that buying the infrastructure of fitness is not the same thing as getting fit. Almost none of those things are fundamental to the original outcome. You can walk into a gym in an old T-shirt, try a few machines, discover what you enjoy, notice what gets in your way and add things when a real need appears.

Maybe after a week you discover that Crocs are not ideal for deadlifts. Fine. Shoes have now earned their place in the system. Please also consider socks.

The people selling all the equipment have a much clearer definition of done than you do: you bought it.

That does not make the products useless. It means an unclear outcome makes it very easy to confuse acquisition with progress.

The same happens with software, tools, projects and personal plans. When you cannot describe the outcome properly, activity is always happy to volunteer as a substitute.

Iteration is not just smaller delivery

I am a big believer in iteration, but not because I joined the Agile church and received my ceremonial Jira board.

Breaking a large thing into smaller pieces is useful, but that is only part of it. If iteration simply means producing the same predetermined outcome in smaller chunks, we have reduced delivery risk without necessarily increasing understanding.

Iteration is a unit of understanding.

You make something, observe what happens, learn, and allow that new understanding to influence what comes next. That middle part matters just as much as the making.

More developers can potentially build something faster. More cooks can prepare more plates. More hands can move furniture around a room. What extra resources cannot necessarily do is compress the time required to notice what happened, understand why it happened, change your mind and let a better idea mature.

Calling that time “delay” is naive. It is research.

The point of an iteration is not merely to complete a smaller amount of work. It is to finish something coherent enough that the next decision can be better informed than the previous one.

Pancakes are surprisingly good product development

Our pancakes at home are probably a better example of iteration than a lot of diagrams I have seen at work.

The original problem was simple: we wanted a quick breakfast for our daughter that was homemade, less processed, included fruit and was good enough that she would actually eat it before school.

The goal was never to produce the definitive pancake.

The first recipe immediately looked more complicated than expected, so it started changing. Did it really need that much milk? We tried half milk and half water. Could we reduce the sugar without producing something nobody wanted to eat? Honey did not really work for us. Bitter cocoa did, and conveniently made the pancakes look chocolatey, which is excellent marketing when your customer is six.

Apples were too crunchy and too plain, so they disappeared. Then came the request for those awful sugary sprinkles. Covering the whole thing in them rather defeated the original purpose, so we compromised: fewer sprinkles, strawberries for sweetness, less sugar in the batter.

Even the quantity evolved. We now make enough for a couple of days: enough to save time if she wants them again tomorrow, but not so much that we have created a frozen pancake warehouse when she inevitably decides she hates them on Wednesday.

The not-perfect pancake. Still doing its job, which is more than can be said for many perfect plans.

Nothing there was optimised in theory. Every change answered something we had actually observed.

Is the pancake perfect? Absolutely not. But “done” had a definition: quick, repeatable, homemade, less processed, reasonably balanced and willingly eaten by the person it was made for.

Once that is clear, compromise stops looking like failure. It becomes design.

Scope creep is often learning that arrived after commitment

The danger of learning late becomes obvious whenever a small idea quietly turns into a much larger one.

Imagine deciding you need a bookshelf.

You find one, order it, put it in the room and realise the desk now looks wrong next to it. If you are changing the desk, you may as well fix the lighting. The new lamp makes the rug look terrible. The rug changes the space enough that perhaps some storage would help, and since you are already ordering from IKEA…

Congratulations. You no longer have a bookshelf problem. You are redesigning the room.

There is nothing inherently wrong with that. Maybe the room genuinely needed redesigning. The expensive part is discovering the new problem after you have already committed to the old solution.

That is one of the more useful ways I think about scope creep. It is not always somebody maliciously adding requirements. Sometimes it is simply new understanding arriving after too much has already been committed.

Scope creep is often learning that arrived after commitment.

Smaller iterations give new information somewhere cheaper to go. You can decide that the bookshelf changed your understanding of the room and make the redesign a separate decision. What hurts is pretending the original job is still the original job while quietly attaching the rest of the house to it.

Careless is not another word for imperfect

There is an opposite mistake to perfectionism that I dislike much more: doing something badly just so it can be marked as done.

Not rough because it is an early version. Not limited because of a real constraint. Not imperfect because somebody tried something and learned.

Just careless.

There is something vulgar about that kind of work.

I would genuinely prefer somebody to say no than hand over something thrown together purely because some obligation forced them to produce it. A no still leaves the possibility that something better could exist. Careless execution removes that possibility and replaces it with something much uglier: visible indifference.

Nothing leaves room for possibility. Carelessness makes indifference visible.

That is why checkbox work feels insulting. The work technically exists, but you can feel that nobody meant it. The objective was not to solve the problem, help someone or make something useful. The objective was to make the obligation disappear.

It is probably one of the sadder versions of the nine-to-five: someone feeling so disconnected from the outcome that completion becomes an act of escape.

I do not need every first version to be beautiful. I do need to feel that somebody cared whether it worked.

Sometimes the first version should look temporary

The two boards in the cover image are a tiny example of this.

For a few months we used my daughter’s small erasable board as a makeshift family calendar. It was not designed for that. It was too small, slightly awkward and clearly temporary.

But it answered the important question: would we actually use a visible reusable calendar?

We did.

Only then did we buy a larger erasable calendar designed for the job.

We did not improve the tool first. We waited for the behaviour to prove it deserved a better tool.

The first version was objectively worse than the eventual one and that did not matter. Its purpose was not to be the final calendar. Its purpose was to tell us whether the idea belonged in our lives at all.

That is a perfectly respectable definition of done.

There is probably no final version anyway

Pizza has taught me this more consistently than almost anything else.

I have changed flour, hydration, fermentation, timings, temperatures, techniques and toppings countless times. Sometimes because I learned something. Sometimes because the oven changed. Sometimes because the ingredients available changed. Sometimes because my own taste did.

Definitely not the final pizza. I have been saying that for years.

It would be slightly ridiculous to declare one pizza recipe permanently finished, because the conditions around it refuse to stay permanent.

The same is true of far more important things. Children change. Relationships change. Cities change. Products change. Society changes. Music changes. The tools available to us change. We change.

A solution can be perfectly sensible in one state and completely wrong in the next.

There is no final version because the conditions do not stay final.

Iteration is not an admission that the previous version failed. Often it is simply recognition that the world did not agree to freeze itself around our previous decisions.

So yes, done is better than perfect

But only if done still means something.

Done should not mean polished beyond reason. It should not mean immutable. It should not mean that nobody will ever touch it again. And it definitely should not mean “technically present, please stop asking me about it”.

A useful version of done has a purpose. It has enough care behind it to test something real, enough clarity to know what it is trying to achieve, and enough humility to accept that reality may disagree.

The question I find more useful than “how do we make this perfect?” is:

What is the smallest version we can make, with enough care, to learn something real?

That version may be a sketch, some glasses on a table, an improvised calendar, a batch of black chocolate pancakes or the first piece of furniture in a room you are absolutely not redesigning.

Yet.

The important part is that every version leaves you knowing more than you knew before.

Otherwise you are not really iterating.

You are just producing versions.