I think this is a good example of the analogy falling apart. A feature that is 99% done may actually be fine. Or it may not be much better than 0% or 50% - that sort of depends on the business side and how incremental a given feature can be and still provide value.
Still, I think in general it's a good idea to be a little more on the "finishing mindset" of things than the "if it builds, it ships" side of things.
> I think this is a good example of the analogy falling apart.
No, it is not.
It is up to you to define what is 100% of your project. If you think something is not worth it, just don't put it in the 100%. Be honest in saying "No, we are not going to do it".
Too many projects linger because there is no will of getting this or that done. Either redefine the project or just f-n do it and be done with it. This helps put definitive end to the project possibly letting you call success on it. It also frees up your mind to work on other stuff.
I take the comment that something that is 99% done in time may or may not not be 99% valuable.
Example: marathon race. If you stop at 99% of the way it’s like not having run at all.
Example: washing the dishes. 99% done is pretty useful
In software dev it’s often a mix of these.
If you need to fix a bug that makes it awful to impossible to use the feature as your last 1% then your current value is 0. The good news is sunk cost aside the last 1% gives you 100-1 value compared to other tasks so definitely finish that off.
If you are doing a task that has 10 discrete stages of feature sophistication the 99% done could mean 90% delivered.
This is why you should try to chunk projects into small iterative chunks that deliver value and do them one at a time until completion. Reality sometimes gets in the way but its a good goal.
When I say redefine the project I mean make an honest decision as to what needs to be completed and what needs not to be completed, and then just finish according to what has been decided.
Lingering work, unfinished projects, are damaging to team productivity. It is better to turn a page and focus on a new task rather than have a dozen of them 90% complete and still occupying everybody's attention.
I try to set explicit success criteria for any task I create (ie Jira ticket). The task is either done or not done and success criteria are reference.
But this is bit more difficult on scale of whole projects.
I agree with that. Project with vague names like “improve speed” or “make it look beautiful” can go on forever! It’s better they are broken into incremental projects “use bootstrap theme” which can be considered done and then if there is an opportunity to decide to stop working on this kind of work and switch to something else.
With software you are never done so you have to decide to be done!
This isn't my understand of what the parent commenter is trying to communicate. I think the point that they're trying to make is this:
A chef could originally decide that a dish is only complete if it is garnished with a terribly rare ingredient that costs an enormous amount of money; this would be analogous to a dev team lead deciding that a new feature will only be considered complete if it covers non-primary use cases or specific pieces of functionality that will add a substantial amount of time to the overall development estimate.
The parent comment is saying that defining that 100% is part of what will impact your possibility/rate of success or failure; the 100% is not predefined or intrinsic, it's a place in time / level of progress that you need to carefully define. If rarity and cost keep you from obtaining the "finishing" ingredient 80% of the time that you make the dish then you're setting yourself up for failure. If you define the feature as only being finished when it covers nearly every sub-feature you can think of then you're setting yourself up for failure.
There also seem to be analogies between quantity and quality. You can get 80% of the way through a feature and decide it's "good enough". The leftover 20% could either be bugs that needed to be fixed or additional features. I don't think leaving out some additional features would be considered skipping the "finishing" phase, but leaving serious unresolved bugs almost definitely would be. An undercooked dish is nearly useless, but one missing a garnish is not.
Yes, I think this "99% counts for nothing" mindset is fair when applied to a task card or pull request. You can play games with semantics and say the journey is all that matters or it's the friends we made along the way, but seriously you can fall into a trap of having 12 unfinished feature branches, at which point most of them are practically guaranteed to go in the trash can. There's value in saying, that's really important, but it's more important to ship this first.
It is.
You don’t choose the requirements, your customers choose them like the customers in a restaurant choose a dish from the menu.
The analogy seems pretty broken, it doesn’t really make sense for several reasons that are written in the other comments.
I think they're talking about unfinished, undelivered tasks. A feature that is 99% done but only lives on your dev branch isn't delivering any value, it's just adding cognitive load as another thing you need to think about, try to remember, worry about forgetting. It's the same concept they're trying to push about inbox zero and only looking at an email once.
I think the next paragraphs clarify a bit.
> Finishing actions clear the mind – a finished plate does not require ongoing attention or memory. In contrast, when unfinished tasks are allowed to accumulate, they clutter the mind and make even the task you’re focused on difficult to complete.
> The same situation applies to knowledge work. It seems harmless to start and stop tasks as new information becomes available. But there is a hidden cost each time we do so. The unfinished task has to be managed and tracked and updated. It takes up space on your to-do list, on your computer or desk, and most importantly of all, in your subconscious mind.
> These small frictions, multiplied by every unfinished task and accumulated over time, can eventually add up to an overwhelming burden that grinds your progress to a halt. You can actually reach the point where it takes all your bandwidth just to remember and track all the unfinished tasks, leaving no time left over to complete them. You have to run as hard as you can just to stand still.
I think this needs to be combined with breaking things down into as small a piece of work as possible. Yes a feature may be valuable at 99% completion, but hopefully that means a whole stack of work items at 100% and a small handful of unstarted work items.
Still, I think in general it's a good idea to be a little more on the "finishing mindset" of things than the "if it builds, it ships" side of things.