Comment by ken | Hacker News Reader

Comment by ken | Hacker News Reader

I'm a little confused by the question. I don't see it applied within the software industry.

Software teams still measure in man-months. We just call them something else, like "story points". I've never seen any estimate or schedule which included team communications costs.

Second-system effect is still just as common as it ever was. We still fix bugs, and in doing so, create other bugs. Many or most systems lack conceptual integrity. We still hire implementors before the architecture is finalized.

I've seen pilot systems only very rarely. I've never seen an architect produce a manual of specifications. I've never seen a surgical team, or anything even vaguely resembling it. I've never seen tool-maker as a dedicated position, even when my manager agreed it would be useful to the team (on the basis that "nobody would want to take that job" even though I volunteered).

The only piece of TMMM that I've ever seen or heard any team try to apply is "No Silver Bullet", and that only as a catch-phrase used to mean "we're fucked either way so don't try". Nobody quoting Brooks has bothered to read that chapter (or that paper) and find out Brooks's criteria for what would constitute a "silver bullet", or try to make one. I can think of a couple examples of partial attempts, but always by UI/PL researchers, never by software engineers quoting Brooks.

Are you looking for "the book everybody knows they should read but nobody actually does"?

TMMM was, broadly speaking, composed of two kinds of things: 1) specific recommendations on procedures (this part looked pretty dated when I read it in 2004) 2) bad news for management, of the sort they don't want to hear - you need to make one to throw away - you can't throw 9 women at a pregnancy and get it done in a month - there are no silver bullets

By and large, the second kind of thing is useful to know, so that you can recognize that particular kind of management mistake when you see it. It won't help you avoid it, unless you're in management, and even then it may not because your hand may be forced from above. But it is less stressful somehow if you can see the pattern in what's happening. "Aha, they are throwing people at a late project, to make it later. Yes, I recognize that."

So, while parts of it are quite valuable and applicable both within and outside the software industry, the actual impact on management behavior is quite small.

As a Brooks reader, I've idly daydreamed about repackaging it as buzzwordy management advice and making a fortune. The issue is that there may not be a market for good management advice, whether down-to-earth or buzzwordy.

I tried to suggest a surgical team at one job, but it didn't really compute for anyone else besides me. (I would not have been the surgeon.)

If you're reading this comment and haven't read Brooks, consider it - not too much of a time investment for the perspective.

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.

Yes, the practices everyone should follow, because they make sense. The - nobody actually does - part is a whole new discussion.

Question popped in my head while reading this para from the book - "Techniques proven and routine in other engineering disciplines are considered radical innovations in the software engineering" What are such practices? What other practices can the software industry derive from other engineering domains?

Reply on news.ycombinator.com