4 ms·

> 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 i

> 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.

kortilla 5y ago
> Either redefine the project This is why the analogy is shit. “Redefining the project” as done when it was 95% there is the same thing as it being good enough.
- dcastonguay 5y ago
  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.
svachalek 5y ago
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.
jimmySixDOF 5y ago
Old advice I got from a Project Director : "90% means you are almost half way done"
- lmilcin 5y ago
  Didn't know it takes Project Director to give that advice. I always thought it is rather common sense, borne from experience: https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule
quickthrower2 5y ago
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.
- lmilcin 5y ago
  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.
  - quickthrower2 5y ago
    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!
tigershark 5y ago
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.

kortilla 5y ago

> Either redefine the project This is why the analogy is shit. “Redefining the project” as done when it was 95% there is the same thing as it being good enough.

dcastonguay 5y ago
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.

svachalek 5y ago

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.

jimmySixDOF 5y ago

Old advice I got from a Project Director : "90% means you are almost half way done"

lmilcin 5y ago
Didn't know it takes Project Director to give that advice. I always thought it is rather common sense, borne from experience: https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule

quickthrower2 5y ago

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.

lmilcin 5y ago
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.
- quickthrower2 5y ago
  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!

tigershark 5y ago

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.