Yes. Maybe more so. The most famous lesson from that book is that you can’t just add bodies to a team and expect proportionate increases in productivity. I think vibe coding means more people simply makes the unmaintainability increase proportionate to the number of added people.
Yes. A small Surgical Team can Vibe Code a CRM today in a week.
The main problem with communication was Context.
What is your opinion on Context length with AI?
The problem Brooks describes around communication has to do with multiplying the number of paths as the team grows. The "surgical team" approach includes a member in charge of documentation at all stages, to give everyone access to the same context.
A small team may "vibe code" something they call a CRM in a week, but unlikely it will work and stand up to requirements changes. Only someone who doesn't understand the business domain would claim they can coax a solution out of an LLM in a few days.
Exactly. Most problems are due to Unclear Requirements before start of a new Project. Build one to throw away.
How do you think this changes with AI?
How? Even with all the intelligence AI cannot Architecture an entire product?
What changes are needed to make it autonomous and self refactoring?
Yes, I have. Sometimes it works, sometimes not, like all team organization strategies. Comparing team organization styles proves close to impossible, too many variables and confounding factors.
Projects fail mainly because of interpersonal conflicts and poor/incomplete requirements. Experienced smart people who understand the domain and have authority to make decisions can succeed with any team organization.
Yes. Maybe more so. The most famous lesson from that book is that you can’t just add bodies to a team and expect proportionate increases in productivity. I think vibe coding means more people simply makes the unmaintainability increase proportionate to the number of added people.
Yes. A small Surgical Team can Vibe Code a CRM today in a week. The main problem with communication was Context. What is your opinion on Context length with AI?
You conflate different meanings of "context."
The problem Brooks describes around communication has to do with multiplying the number of paths as the team grows. The "surgical team" approach includes a member in charge of documentation at all stages, to give everyone access to the same context.
A small team may "vibe code" something they call a CRM in a week, but unlikely it will work and stand up to requirements changes. Only someone who doesn't understand the business domain would claim they can coax a solution out of an LLM in a few days.
It is. So much so that I quoted him and even included a photo in my latest article[0] about AI pair programming.
[0] https://levelup.gitconnected.com/you-are-bugs-improving-your...
Exactly. Most problems are due to Unclear Requirements before start of a new Project. Build one to throw away. How do you think this changes with AI? How? Even with all the intelligence AI cannot Architecture an entire product? What changes are needed to make it autonomous and self refactoring?
Has anyone worked on a project with the "Surgical Team" organization? If so, how well did it work compared to other team organizations?
I think the idea had a lot of merit, but have never seen it in practice.
Yes, I have. Sometimes it works, sometimes not, like all team organization strategies. Comparing team organization styles proves close to impossible, too many variables and confounding factors.
Projects fail mainly because of interpersonal conflicts and poor/incomplete requirements. Experienced smart people who understand the domain and have authority to make decisions can succeed with any team organization.