I don't know if it's a good list for tech leads, wannabe or otherwise, but one could do worse in choosing three books.
I do take issue with the the Mythical Man Month blurb, though. My copy has disappeared from my bookshelf again, but IIRC 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. But it's the one that allows us all to pretend we read it. Quick quiz, hot shot: what did you think of the surgery team metaphor? Another thing few mention about MMM: at least some parts are noticeably dated. (But without a copy in front of me, I don't recall which parts.) So, good book that we probably all should actually read instead of just spouting about nine pregnant women, but not all of it will be relevant today.
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.
> 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.
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.
> 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.
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
> 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.
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.
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.
I do take issue with the the Mythical Man Month blurb, though. My copy has disappeared from my bookshelf again, but IIRC 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. But it's the one that allows us all to pretend we read it. Quick quiz, hot shot: what did you think of the surgery team metaphor? Another thing few mention about MMM: at least some parts are noticeably dated. (But without a copy in front of me, I don't recall which parts.) So, good book that we probably all should actually read instead of just spouting about nine pregnant women, but not all of it will be relevant today.