>That sounds specious - grass is greener fallacy. The evidence was that the CP team failed at the job. But where is the evidence that the architecture team would succeed?
Anybody who has worked for a couple of decades of large software project, doesn't need any, cause they have seen this play out time and again. Brooks doubly so -- he literally wrote the book on software development timelines.
Sure, technically you're right.
But it's not like every piece knowledge needs to come packaged in a fancy LaTeX, with confidence intervals, and control groups. Sometimes experience alone is enough to assure us that the rain is wet and that a team of 150 will invariably fail in this way when assigned such a task compared to a team of 10.
Seems like a good way to go would be 15 isolated teams of 10. Some teams might make the schedule. Pick the best project at that point. Big bonuses for the people that get it done and extra for the final winners. Seems like a huge waste of effort, but it looks like that is the way to go. This would be similar to what happens when a company just buys a small startup that has created what they need.
Anybody who has worked for a couple of decades of large software project, doesn't need any, cause they have seen this play out time and again. Brooks doubly so -- he literally wrote the book on software development timelines.
Sure, technically you're right.
But it's not like every piece knowledge needs to come packaged in a fancy LaTeX, with confidence intervals, and control groups. Sometimes experience alone is enough to assure us that the rain is wet and that a team of 150 will invariably fail in this way when assigned such a task compared to a team of 10.