• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Mythical Man-Month

 
Marshal
Posts: 65806
250
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now, that used to be a classic book about this sort of problem. I remember it explained about why a 30‑second phone call would lose 30 minutes' production and that sort of thing. Have things moved on since then? Or do such problems still apply? How does your book differ? Is it only useful for people working in teams rather than somebody working on their own?
 
Marshal
Posts: 14048
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting. It's been a while since I last cracked open my copy of the 20th Anniversary Edition but I've never thought of the book like that, as one about impediments. At least not specifically. As far as things moving on, I think anyone needs to look no further than the project that they're on to see that Fred Brooks' decades old prediction that "a decade would not see any programming technique that would by itself bring an order-of-magnitude improvement in software productivity" still holds true (emphasis on "by itself" mine).

Certainly, advancements in technology and techniques have the potential for vast improvements in productivity and there are many examples where they have been proven to increase productivity by at least an order-of-magnitude. At HackOHI/O last month, I had to laugh when one of the other mentors I spoke to said that companies like Amazon.com were deploying to production "3 to 4 times a day. That's awesome!" He was a bit incredulous when I told him the correct figures: "If I remember correctly, it's actually about every 12-14 seconds. At Google, I believe the rate is every 7 seconds. To production. All the time."

In contrast, my wife is on a team that considers itself as doing "Agile Development" and they are quite happy to regularly release to production every three months instead of just once a year as they did prior to moving to their "Agile" process. I put the word in quotes because from everything that my wife has told me about how they do things, their process is really more of what I call "Water-gile Scrum" than anything.
 
Junilu Lacar
Marshal
Posts: 14048
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On that note, I guess you might say that perhaps impediments can be relative. Google's "every 7 seconds to production" rate would be unimaginable at my wife's company, a large commercial bank. At Google, the red tape that slows down the deployment process at my wife's company would be seen as a huge impediment. At my wife's company, that same red tape, aka "Due Diligence", is probably seen as a necessity and a requirement for fulfilling their regulatory compliance obligations.
 
Saloon Keeper
Posts: 5809
146
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't remember MM-M  being about that sort of thing, either, and a quick scan of The Mythical Man-Month seems to bear this out. Maybe Campbell was thinking of another book?
 
Rancher
Posts: 1041
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:... regulatory compliance obligations.



I had worked long for a bank and have been working in healthcare. The regulatory compliance obligations at the healthcare appear to be more severe than those in the finance.
 
Campbell Ritchie
Marshal
Posts: 65806
250
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is a long time since I looked at it, so I might be mistaken.
 
Junilu Lacar
Marshal
Posts: 14048
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As an aside, I just learned through the wonderful power of Google that Fred Brooks cited a paper by Mel Conway and was apparently the one who first referred to what Conway wrote about as "Conway's Law."  As I mentioned in another thread in this forum, the structure of an organization can actually be considered as an impediment. In fact, Organizational Structure is right at the top of Bill Wake's Catalog of 100 Impediments, which Tom's book cites.  So I guess Brooks' MM-M does have a real connection to impediments after all.
 
Junilu Lacar
Marshal
Posts: 14048
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's what Brooks wrote:

In Chapter 10 of "The Mythical Man-Month," Fred Brooks wrote:
Who: organization chart. This becomes intertwined with the interface specification, as Conway's Law predicts: "Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations."[1] Conway goes on to point out that the organization chart will initially reflect the first system design, which is almost surely not the right one. If the system design is to be free to change, the organization must be prepared to change.


How many organizations do you know of that are willing to change their structure in order to improve their system's design? I think this is why Bill Wake puts these impediments at the top of his catalog.

Campbell is right about the MM-M book being a classic. I bought my copy of the 20th Anniversary Edition in January 2000 (I signed and dated the inside title page), five years after it was published. For much of it to still be very relevant today certainly makes it a true classic. Thanks for making me take a look at it again, Campbell.
 
Author
Posts: 7
5
Mac C++ Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Strictly speaking, I don't think I had drawn any conscious connections with Mythical Man Month (but thank you - I love it). Like many folks I admire it as a classic and I think that much, if not all of it holds true today. Taking the example of the of the 30 second phone call, I think that the cost of delay or interruption is just as high today as it was when MMM was first written. If anything, I might even go so far as to posit that the cost of interruption has increased. In Fred Brooke's day, I think the model of the development team was still predominantly one of individual chief surgeons working together, but often fairly isolated by todays collaborative team standards. Interrupt any one of them with a phone call and it was very likely that no one else would notice. Everyone keeps working away in their cubes. Today on the other hand, we have innovations in collaborative behavior like pair programming that have served to dramatically tighten the bonds and the influence between team members. Now when you call somebody on an Agile team, it's very likely you are interrupting two or (heaven forbid) even more people. So you can take that interruption cost of 30 minutes and multiply it by the number of people on the team (or some percentage thereof). Ouch.

So, in a word, YES, the problem is still there. In fact, if anything, I would argue it has gotten worse.
 
Junilu Lacar
Marshal
Posts: 14048
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tom Perry wrote:So, in a word, YES, the problem is still there. In fact, if anything, I would argue it has gotten worse.


The link may seem tenuous but I'm going to make it anyway. I think it has something to do with how we teach and learn. I've been citing Andy Hunt's book, Pragmatic Thinking & Learning: Refactor Your Wetware" quite a lot since I read it. It's a wonderfully insightful book and there are quite a few sections in it that I think are relevant to what I discuss in the other thread about insensitivity and obliviousness. We also have had a few discussions in these forums about the kind of instruction we see students getting, how we think it's focused on the wrong things, how we feel students are getting shortchanged, and perhaps some ways we can improve.

I think The Software Craftsmanship movement plays a very important role in stemming the tide. Unfortunately, not very many students or even software professionals are interested in it. After facilitating the Global Day of Code Retreat event in Columbus OH last October, I told my colleagues at work that I'd be willing to facilitate one for our team. Only one out of the five developers we have stayed the whole day. Two others joined remotely and were in-and-out of the sessions. The other two didn't show up at all. So, it's pretty much par for the course that you'll get 1 out of 5 people really interested and committed to doing something and go that extra mile to improve themselves.  This also seems to be in line with the statistic that 1 out 10 software developers is an order of magnitude more productive than the others.

I think apprenticeship/mentorship programs will help. This is another thing encouraged by the Software Craftsmanship movement. I've been lucky to have learned Agile from some of the best in the industry, not only through their books and other writings and my own diligent study of them but also through direct, personal contact and instruction from Lyssa Adkins (Agile Coaching), Ellen Gottesdiener (Agile Requirements), Diana Larsen and Esther Derby (Retrospectives), and many of the folks here at JavaRanch like Ilja Preuss and Lasse Koskela. Being able to converse with folks like these and pick their brains helps you open up new horizons and perspectives and enriches your learning experience. But you have to be open-minded and willing to learn, experiment, and most of all, fail. If there's one thing that keeps you from learning, it's the inability to accept or even risk failure and move on from there.
 
Saloon Keeper
Posts: 21132
131
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of the central propositions of M3 was the Chief Programmer Team concept, which was organized like a surgical team, with a chief programmer (architect), assistants, and support personnel (for example, a Librarian to keep up with the documents). It was much ballyhooed on a famous project for the New York Times and almost immediately descended into obscurity. I'm thinking that it didn't work as well as expected, although since expectations of any software project consist of unrealistically small expenditures of time and money, I don't know how much of that was failure of CPT and how much the same problems that every software effort of magnitude encounters.

In any event, these days, the likelihood is that rather than a team of finely-tuned specialists, there's a lot of cases where a few people not only are expected to handle the various CPT roles simultaneously, but also serve as DBA, LAN administrator, and whatever else can be dumped on them. So forget CPT.

There is, I believe, a revised and extended edition of M3. One of the things that Brooks did was refine his famous law: "Adding more people to a late project makes it later". Given the right circumstances it can be ameliorated. Unfortunately, nuances aren't popular with management, so this was a little like a license to abuse as far as I'm concerned.

One thing that Brooks did assert was that critical programs - such as OS's - had no business being written in assembly language. IBM took his advice to heart and created PL/S for their OS products, though they didn't share it with outsiders. The original CP/M was likewise written in a language called PL/M, The "DOS" part of AmigaDOS was written in a C-like language called BCPL, and, of course both the Unix and Unix-like OS's as well as much of the Microsoft product line are written in C. Oh yeah, and the Primos OS was written (excluding the core dispatcher and a few services) in Fortran - they actually optimized their instruction set for it. So, I think you can call that a win for Fred Brooks.
 
Campbell Ritchie
Marshal
Posts: 65806
250
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:. . . Chief Programmer Team concept

I had forgotten that part of MMM.

. . . a C-like language called BCPL . . .

I always thought BCPL preceded C and K&R used BCPL as a sort of prototype for C.
 
Tim Holloway
Saloon Keeper
Posts: 21132
131
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:

Tim Holloway wrote:. . . Chief Programmer Team concept

I had forgotten that part of MMM.

. . . a C-like language called BCPL . . .

I always thought BCPL preceded C and K&R used BCPL as a sort of prototype for C.



That's my understanding also. You'd probably know better than most, since it was sardonically referred to as the "British Cruddy Programming Language".

The DOS in AmigaDOS was originally a post-baccalaureate project known as "Tripos" (which is an academic dig). I think it may have been someone's Masters at Oxford, but absolutely none of that is certain to me, much less who the original author(s) was/were. It was actually a horrible fit for the Amiga, since it used word-level addressing (4 bytes) and had a grow-down stack. The kernel of the AmigaOS was actually written in Assembly/Green Hills C, although it mapped exceedingly well to C++ as I found to my profit. It was modelled on Djikstra's T.H.E. OS, I think, and most of the essential OS structures were doubly-linked lists. Linked list functions were part of the nuclear function library, in fact.

Melding the C-based byte-addressed upwards-stack architecture of the kernel to the word-addressed downward-stack BCPL DOS and on to user-written C-code DOS device drivers was one of the more challenging aspects of systems-level programming for that platform.
 
Campbell Ritchie
Marshal
Posts: 65806
250
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You were right; I was mistaken. It wasn't Fred Brooks, but Joel Spolsky.

Part 8 of that Joel Spolsky link wrote:If a coworker asks you a question, causing a 1 minute interruption, but this knocks you out of the zone badly enough that it takes you half an hour to get productive again . . . .

Also in Joel Spolsky Joel on Software Apress 2004 page 25.
 
Ranch Hand
Posts: 974
11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tom Perry wrote:So, in a word, YES, the problem is still there. In fact, if anything, I would argue it has gotten worse.



And it is triple as bad for people like me who are distracted easily! Nevertheless, try to explain that to your (Agile enthusiast) manager that has another way his brains works than you have.
 
Jan de Boer
Ranch Hand
Posts: 974
11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:You were right; I was mistaken. It wasn't Fred Brooks, but Joel Spolsky.

Part 8 of that Joel Spolsky link wrote:If a coworker asks you a question, causing a 1 minute interruption, but this knocks you out of the zone badly enough that it takes you half an hour to get productive again . . . .

Also in Joel Spolsky Joel on Software Apress 2004 page 25.



Okay, another book, I firmly agree with the content though. I would like to read that one.
 
Campbell Ritchie
Marshal
Posts: 65806
250
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I like the two Joel Spolsky books, but their entire content can be found by exploring Spolsky's blog, which you will find from the link I posted earlier.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!