18 ms·

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 som

by ken 7y ago

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"?

juped 7y ago
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.
- deleted 7y ago
  [deleted]
bjterry 7y ago
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.
- ken 7y ago
  > 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.
rossdavidh 7y ago
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.
joddystreet 7y ago
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?

by ken 7y ago

juped 7y ago

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.

deleted 7y ago
[deleted]

bjterry 7y ago

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.

ken 7y ago
> 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.

rossdavidh 7y ago

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.

joddystreet 7y ago

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?