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