I really think that the Sharp Tools essay is pretty significant. That's an initiative that I'm really trying to push at my work. In the one essay about how adding people can make a project even more late... I think too few people focus on the significance of partionable tasks -- that is, when you're a tech lead, it's very important to understand what tasks should or should not be partitioned, and equally as important, _how_. For example: If you need two long ditches dug and have 2 workers - you might say "you dig ditch A, and you dig B". Or you might say "You start at the north end of A and you at the sound end -- dig towards each other and meet in the middle. Then, repeat for ditch B" But you would NEVER say "You dig the top half of ditch A, and you dig the bottom half, meet in the middle, and repeat for ditch B". Not enough managers/leaders put an emphasis/importance on understanding how to partition a task -- or that it often requires more than MBA knowledge to do so.

Depends on the ditch. That's effectively how the Loon Lake Powerhouse was constructed. Traversing the entrance shaft funicular you can see the bobble where the upper and lower "ditches" deviated somewhat.

Upper American River Project, east of Sacramento.

https://en.wikipedia.org/wiki/Upper_American_River_Project

Video tour:

https://youtube.com/watch?v=LHYnxvp-hJY

Brook's law is also outdated. It's mostly only relevant for when you deliver your software with a forklift.

Even Steve McConnell of Code Complete and Rapid Development has argued against it:

https://stevemcconnell.com/articles/brooks-law-repealed/

> Brook's law is also outdated. It's mostly only relevant for when you deliver your software with a forklift.

Hmm... not sure I agree with this. A few points come to mind:

- Some portions of a project become hotspots at different times and have a natural code concurrency limit (it may not be 1, but certainly 10 people can't make changes to the same class or other critical code path concurrently)

- Onboarding is a real thing. It requires current staff to train newcomers, at the very least. At worst, they have to account for the newcomer's coding/architectural misses

- Communication and consensus building with more folks takes exponentially more time (or is it combinatorial, I can't keep that straight).

In a SaaS world the value stream is broken up and delivered as appropriate. What does it mean for a project to be late if there is a value stream constantly being delivered?

Onboarding is a real thing but Brook's calculations are absurd by today's standards. 1 Month to onboard someone? We have developers committing code in their first week. Sometimes day 1 or 2.

Read McConnell's essay. It's v. good.

At Google, engineers start committing code in their first week too.

That doesn't mean they're fully on-boarded until 6 months in.

I was on a project where we added 6 people to an 8 person team in 2 weeks. Velocity stayed exactly the same as before for a sprint or two but quality issues jumped. We then spent an enormous portion of time on bug fixing. It took about 2 months before the overall team really saw a net benefit to velocity by adding those people.

Brooks exact numbers might be come from a different time, but the principle holds unless you have an uncommonly decoupled set of problems.

> We have developers committing code in their first week. Sometimes day 1 or 2.

If you're doing anything complex (which can just be: if your codebase is more than a year or so old) than the quality and velocity of code someone can contribute on day 1 is vastly lower than they can a month later.

I see the Mythical Man Month tossed around as an excuse for not trying sometimes - by people who haven't even tried to split up and spread out chunks of work in parallel - but onboarding cost is definitely real.

You gotta evaluate "can I get enough overall throughput at this point in time to make up for the total efficiency lost" and also the rest of the business priorities outside of this one project.

Microservices are all about trying to get around Brook's law. It is very much still in force.

> Quick quiz, hot shot: what did you think of the surgery team metaphor?

Interesting side discussion -- I have just started reading the book, but I did think that the idea of the surgical team was an interesting and radical departure from the standard "two-pizza team" pattern of a few developers that are considered roughly equivalent aside from minor leveling changes. My personal thoughts were that it would be hard to see success with the model unless you made sure all the roles were recognized as being equally important towards the success of the team.

I had wondered about (and rour comment inspired me to look up) whether people have had any experience trying it out, https://softwareengineering.stackexchange.com/questions/3552... has some interesting references and pitfalls of the approach.

The best of Brooks is the silver bullet article. It was included in newer editor editions of the book. Great to understand why the shiny new visual programming product someone is trying to sell your company won't improve your productivity

I was quite sad the first time I brought up the surgery team metaphor with my surgeon friend and she said that's not how it works at all.

> the "adding more people makes it later" bit was just one of many essays in that book, but it's the only one people ever mention

The reason it is continually mentioned is companies make this mistake over and over and over again. I am witnessing it happen right now on a project, and I have seen it happen many times before.

It’s been at least a decade since I read it, but isn’t there a whole chapter on using a mouse AND a keyboard to increase productivity? :D

So yeah, some of it has dated, and some of it I disagree with, but it kills me that a lot of the lessons are still not learnt 45 years later.

The concept that a complete document/tested/integrated product system takes much more work that the base product is also a good one.

That said, I'm not sure I'd recommend the whole book today.

Might also include Soul of a New Machine and Showstopper!

I vaguely recall reading Soul of a New Machine years ago, but I don't recall there being a lot of SWE lessons in it. Maybe it was because I read it so long ago. Mind sharing a few things you got from this book?

It's been a long time since I read it as well and I knew the hardware/microcode people in the book better than the OS folks--and I think the book probably focused on them more. Maybe it's not really SWE lessons per se as so much as just a really good account of a computer systems project. (I worked at Data General for many years though I joined a few years after the events of the book.)

Showstopper (about the development of Windows NT) is more focused on software obviously.

The greatest lesson I took from the book was "no mode switch".

This is an excellent principle for software development as well IMO.

Now, I love the story about the biblical quantities of paper documentation that was produced, distributed, and consulted every single day during the development of OS/360. But broadly the book has aged poorly -- it's quite thoroughly misogynistic for example -- and absolutely does not get a pass since the author explicitly declined the opportunity to update it in later editions. Moreover, the writing is nothing special, and the ideas have seeped quite deeply into our culture, so it's not necessary to read the primary source. Folks today would be better off reading the Wikipedia page which does cover the main concepts, including the surgical team.

"Misogynistic" how exactly? I've seen people call it misogynistic because it introduced the term "man-month", so forgive my skepticism.