It's 99% done
This is what I've heard on the first day of a new project months ago.
I'm happy to report that, today, after several weeks of work, we are still 99% percent done. Or maybe I should say 99.9% done. Math is awesome, there's always room to add yet another nine to make it right.
I have enough experience to know that when 99% or almost are put in front of the word done, they actually mean nowhere close. The issue is that done does not mean anything until it's given a definition people can refer to.
When hard things surface, having a blurry definition (or none at all) justifies doing the easy work instead of the right one. Moving a ticket to a column named Done does not make the project one ticket more successful.
We need a definition of done, otherwise...
...There's No Finish Line
This product was supposed to be launched years ago. But without a definition of done, it was always not done, by definition.
Being a commercial endeavor, profit should have been the success metric guiding the effort. Instead, without boundaries, the product grew to a complicated aggregate of features that accrued bugs and welcomed scope creep.
...Developers Just Translate Specifications
Don't get me wrong, coding is awesome but I'm tired of building things that have zero positive impact. When developers are tasked with translating specifications into code, they will just do that. Or worse.
If people are not given the incentive to care about the product, they will have fun elsewhere. For example, by introducing accidental complexity. Or at least that's what I did in the past.
...We are Building the Wrong Thing
A ticket containing just a specification without any additional context can be moved forward in two ways: by doing a bad job or by doing a perfect one. Since the latter is unattainable, the result is destined to suck.
If we don't know who's going to use the feature and how, the only way to develop it is to cover all possible cases, many of which conflicting. Good luck with that!
...We are Building the Wrong Thing Wrong
What happens when you build for several months without testing with real users and real data? An application that doesn't work with real users and real data happens.
But it works on my machine. Yes, in development, with one user, and three products. It's going to be fun to fix months of work done on top of a slow infrastructure that leaks memory.
Have a Definition of Done in the Ticket
I have a wild idea. Maybe we should keep the definition of done in the ticket and let everybody know what we are trying to achieve.
Yes, that means we need to figure out what we are trying to do before we do it. But it doesn't seem such a bad idea.