A lot of people in this thread seem to have a gripe with
> Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that.
I think some of those comments signal that they misunderstand the point. There are two reasons to decompose a system before starting to build it:
- To quickly eliminate solutions that are almost guaranteed not to work, and
- To find consistency boundaries allowing you to structure work efficiently.
These two things speed up development, they don't slow it down. What they have in common is that you don't need a very detailed decomposition to leverage the benefits. Usually decomposing into at most 5 components or fewer will get you there.
What the point in the article talks about is decomposing into the smallest details trying to produce a detailed design containing finely grained subcomponents ahead of time. That, indeed, will take more time and may not even generate a better result, as the article says.
I wouldn't disagree that decomposing a system in this way before implementation is a net positive, however I think different stake holders view plans like these very differently. If you discover partway through development that the library you planned to use for a feature will not work and as a result have to revisit your plan, then some stake holders see that as a failure or delivering late because to them the original plan was an iron-clad guarantee whereas to developers that's just an expected part of the process where not everything can be known ahead of time
> Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that.
I think some of those comments signal that they misunderstand the point. There are two reasons to decompose a system before starting to build it:
- To quickly eliminate solutions that are almost guaranteed not to work, and
- To find consistency boundaries allowing you to structure work efficiently.
These two things speed up development, they don't slow it down. What they have in common is that you don't need a very detailed decomposition to leverage the benefits. Usually decomposing into at most 5 components or fewer will get you there.
What the point in the article talks about is decomposing into the smallest details trying to produce a detailed design containing finely grained subcomponents ahead of time. That, indeed, will take more time and may not even generate a better result, as the article says.