At an event recently, I had a chat with someone after one of my sessions. I had been speaking on DevOps and ways to better structure your team and build software. After the session, one person asked me if I’d read The Mythical Man Month and if I felt we’d gotten a lot better at building software since that book was published.
I do think we have gotten better, way better, in fact. I caught another review of the book a while back from the Pragmatic Engineer. That review looked at what’s changed in 50 years since the first edition, as well as contrasting the world today. You have to subscribe to read that one, but I’ll give you a few thoughts from me on the book itself and the review.
Perhaps the most famous part of the book is the notion that adding more people to a late project makes it later. That doesn’t always happen in other fields, where people can tackle separate tasks and get things done. Certainly feeding hay to horses goes quicker with more people. However, in software, things don’t work that way. Perhaps this can work better today if we use microservices and separate architectural sections, but for any single piece of software, this often holds true. Even for microservices I’m not sure it’s true because developers take time to get productive.
And yet, people still try to add more staff to projects in the hope they’ll complete the application sooner.
Another great quote from the book is that programmers (developers today) can build castles in the sky. We can use our imagination to create, polish, and re-work in a way that isn’t easy in the real world. That, along with the joy, complexity, and opportunity to learn, are why people program. The Pragmatic Engineer’s view notes that there are other reasons, such as so much of the world uses software that people want to be a part of that, and the career is lucrative. I agree with that for sure. Working with code is a good job in many ways.
The book notes several challenges to building large systems, such as precise coding, lack of control, dependencies, debugging, and obsolescence from delays. Of these, some are true, but we have tools, like SQL Prompt, that help us avoid poor typing of code (and CI for checking). We also have moved to a much faster pace of delivering parts of a system and evolving them, so we are often targeting just what our customers need, at an apparent faster pace. I’d also say that being able to deliver something quickly is important, as customers are quick to move on if you cannot.
One interesting part of the book that isn’t quite so relevant is the discussion about why projects are late. While I don’t know we estimate better, we certainly are better at getting smaller pieces of work done, which might hide some of the delays for larger features. We have so many more ways to track work and ensure we aren’t forgetting what we have planned. There are also many more good managers today that empower their people. These are also the things in DevOps that have vastly improved how we build software.
Onboarding is a major issue in the book, as finding staff who knew tools/techniques/whatever was hard back then. There just weren’t many people. Today, we struggle to onboard some people, but I’d like to think that it’s not the same as in the past. However, I certainly think database techies in many cases haven’t kept up or learned a lot of core software dev practices, such as version control, CI, and lots of things we bundle into DevOps. At the same time, I think we’ve burdened many people with full-stack development when they don’t have a good understanding of core technologies, like databases and networking. I still think onboarding people quickly is a major advantage for any company that needs to build software and compete with others in their industry.
In the book, Brooks talks about the 10x engineer, a hotly debated topic in the modern software world. Are some people much more productive? I do think so, though if they are 10x as skilled as many others, I’d argue the others aren’t earning their salaries.
If you’ve never read the Mythical Man Month, pick up a copy. It’s worth your time as a developer or a DBA.
Steve Jones
Listen to the podcast at Libsyn, Spotify, or iTunes.
Note, podcasts are only available for a limited time online.
Voice of the DBA 
I can’t say this is true in all areas of software development but within the world of video gaming, a bigger team does not automatically equal a better or even more quickly delivered product. The truly innovative things in gaming tend to come form the smaller teams. It’s like having too many cooks in the kitchen. It’s fine to have a Sous chef, a Chef de Partie, a Commis Chjef, a Grde Manager and so on. What doesn’t work out so well is when you have multiples of each of these types especially more than one Executive Chef. The best kitchens are the ones with the smallest staff not the one overflowing with Chefs.
This is a philosophy I believe applies most everywhere. When a company grows so large that the executives have no clue who the employees are, don’t even recognize them and they become numbers instead of people something get’s lost and the business is not made better for it. It may lead to more profit but not always a better product/service. I believe a society made up of many more smaller results in far superior products & services then one of a few mega-corporations. The larger you get, typically the cheaper you can produce something like when the auto industry adopted the assembly line but you loose that personal, artist touch. Instead of purchasing something of fine craftsmanship that does cost more you get something viable at a lower cost.
A larger publisher like Ubisoft seeks to ship a commercially viable product.
A small independent shop seeks to ship a work of art.
These are “in general” as you will have scammers but those are the exceptions. I believe the smaller the team the better the product.
LikeLike
Maybe true. I think small teams also sometimes take a lot of shortcuts and do things expediently and not necessarily safely or in a way that scales. I think it’s all down to people, and there are some amazing products shipped with lots of people. Teslas are one peice of software that is pretty cool, with a lot of people working on it. I’d argue some of the other companies with lots of engineers didn’t do a good job.
LikeLike
The quality of the personal always matters regardless of team size. Bad/incompetent management however can nullify even a great team.
I actually got to test drive Tesla or should I say test ride one a few weeks back and was very impressed with the innovations Tesla made separate from the engine. Their self-driving feature is almost unbelievable, like something out of a Sci-Fi movie. When I tested it, the self driving mode, as soon as it pulled out of the parking space someone cut in front of the car and I reacted w/o thinking and the car reacted faster.
I really wish the industry would adopt some of the non-EV engine innovations of Tesla like the self-driving. I know that other manufacturers have assisted driving but my understanding is that Tesla is the only one that uses GPS and more to get it was perfect as they do thus why it’s self driving for a Tesla and assisted driving for others.
LikeLike
Management is a crucial part of driving things forward.
WRT the Tesla, it’s both amazing and not amazing. I love the MY I have, but the self driving works great in good conditions and a happy path. Sometimes it doesn’t work well at all. Stop signs are mostly great, sometimes weird. Unprotected left turns are worrisome and problematic. Bad weather, I don’t trust it.
Tesla uses some GPS, but mostly it’s vision and evaluating things in ream time
LikeLike