Comment by bjterry | Hacker News Reader

Comment by bjterry | Hacker News Reader

Parent Full thread

Many of your points are accurately stated.

Story points are different from man-months because they are part of a continuous calibration feedback loop. They really differ pretty fundamentally from man-month style estimates in waterfall software delivery. If you are calibrating your story points, they should naturally include team communication costs if those costs are somewhat stable.

Brooks' core insight has been well-heard though. Everyone I work with in software engineering knows that adding more engineers to a project will not get it delivered faster when it's already in crunch time.

In general, "agile" development differs in a lot of ways from what software development looked like when Fred Brooks was writing. If you are delivering software in small increments, making small adjustments and receiving continuous feedback from users, a lot of his advice maybe is not relevant. Hiring implementers when you are still architecting a MVP version of a feature which you will test with customers then rearchitect as necessary is not as big a problem as hiring them when you are working on the final architecture of a system which will be years in development and deployed in a very expensive once-per-year fashion.

Companies (well-run companies, that is) have surgical teams in spirit, in the sense that the more complex projects are taken on by engineers that have successfully executed the most complex projects in the past, and work with more junior engineers on coding those projects. And there are often development teams with people fulfilling different roles as part of projects. Many companies have teams responsible for development tooling, including pretty much every FAANG and most large startups.

In general, it would be surprising if Brooks had happened to be exactly right in all of his observations writing 40 years ago. In well-run companies, we see a lot of things which Brooks was pointing to were exactly accurate, but we also see that in many ways we've moved past his predictions of the best way to do things. In badly run companies, many are still making the mistakes Brooks talked about, because they are attractive or "obvious" ways of thinking about software development.

> Companies (well-run companies, that is) have surgical teams in spirit, in the sense that the more complex projects are taken on by engineers that have successfully executed the most complex projects in the past, and work with more junior engineers on coding those projects.

That doesn't sound anything like a surgical team to me. It just sounds like you're mixing experience levels to train new people.

As Brooks said (paraphrasing Mills), "instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity." The anesthesiologist and radiographer and nurse aren't just less-experienced surgeons. They're not surgeons at all -- and I hope they're just as skilled at their jobs as the surgeon is.

There is a qualitative difference in results when you have a dedicated person in charge of something.

> In general, it would be surprising if Brooks had happened to be exactly right in all of his observations writing 40 years ago.

Why? Has human nature changed in 40 years? This isn't like reading Plato, where he simply made up things he didn't understand. On the contrary, I would be much more surprised if the nature of team productivity had changed in only 40 years.

> That doesn't sound anything like a surgical team to me. It just sounds like you're mixing experience levels to train new people.

I think I'm more saying that we have moved toward a specialization of labor that supports the software engineer in a different way, even though it hasn't ended up looking like a surgical team. We have product managers who understand the user's needs and organize feedback sessions, we have product designers who are experts of UX design, we have junior engineers that implement components with the oversight of the more senior engineer, etc. It has ended up being more collaborative, and it's not clear to me that it would be better if instead we tried to organize it around a single person who was the overall "surgeon" who did the key aspects of all this work with the others in a supporting position.

In some companies there is a "directly responsible individual" who is in charge, but in others there isn't. Are they acting as a surgeon in that case, or are they doing project management? It depends on the organization. How much ownership that person has and what is the impact on that person of success and failure? It's hard to analyze a different organizational framework as it relates to Brooks.

> Why? Has human nature changed in 40 years? This isn't like reading Plato, where he simply made up things he didn't understand. On the contrary, I would be much more surprised if the nature of team productivity had changed in only 40 years.

Brooks' writing wasn't grounded in fundamental human truths, it was grounded in his observations of software projects that existed in 1975 and related observations of how work was performed in other industries.

My intuition is that if there are Way A through Way Z ways of doing things that are optimized for A through Z different types of organizational problems, Brooks was saying "Way D is the best for software projects." But because we now work on different types of problems (much shorter feedback loops, higher levels of abstraction, users with higher levels of sophistication, greater importance of software ecosystem) maybe Way E (Silicon Valley style agile, lean product management, etc.) is more appropriate. Since Way E has been successful in the market, it at least seems adaptive. Otherwise companies would have a strong incentive to change to Brooks' Way D.

Reply on news.ycombinator.com