The benefit of the tiny tasks model is that you don't build stuff people don't care about. Features/bugs exist in a survival of the fittest world and the lowest priority ones never get built/fixed. This was one of the big problems with "hero in the back office coding for months and emerging with a product".
The tiny tasks model also lets you ship updates to the end user much faster and also ensures the product is never in a half-broken state. It's also more robust when you don't have a team of all-star programmers.
I agree that building big projects on your own (or with a tiny team of motivated folks and no mandated meetings) is way more fun and sometimes far more productive. But that's why I think it's important to incorporate things like hackathons and prototype phases into the engineering department. Each software development model has its strengths and should be used when appropriate.
The tiny tasks model also lets you ship updates to the end user much faster and also ensures the product is never in a half-broken state. It's also more robust when you don't have a team of all-star programmers.
I agree that building big projects on your own (or with a tiny team of motivated folks and no mandated meetings) is way more fun and sometimes far more productive. But that's why I think it's important to incorporate things like hackathons and prototype phases into the engineering department. Each software development model has its strengths and should be used when appropriate.