Mythical Man Month - Computerphile

For those of you admiring my sweater it was bought for me by my daughter and is from the Nottingham-based Paul Smith men's fashion house. Not as famous a name as Ralph Lauren (say) but Nottingham is very proud of Sir Paul (as he now is)

I've been in industry nearly 20 years and time and again I've had to say: "9 women cannot have a baby in 1 month." Great job, Prof!

I read "The Mythical Man-Month" in just one hour by paying an offshoring company to have each page read by a different person. #efficiency

"Non-partitionable task" is now in my explanatory vocabulary when interacting with unrealistic management.

Another day of Professor Brailsford, casually blessing the internet.

This principle has been known since prehistoric times. A tribe of 10 cavemen can team up and kill a herd of 10 mastodon in 1 day, but 1 caveman cannot kill a herd of 10 mastodon in 10 days. Also known as "The Mythical Mammoth".

The way I'm most familiar with putting it is "Adding manpower to a late software project makes it later." The expected speedup is O(n), but the increase in communication complexity is O(n^2), hence the minimum on the complex project curve.

I ran into the mythical man month problem at my previous job. Upper management decided to add a bunch of offshore developers to the team, thinking it would make us so much more efficient because we'd be staffed almost around the clock. The time zone difference of close to 12 hours made communication incredibly difficult. We couldn't effectively collaborate with each other because any meetings had to take place during some people's off hours. Getting email responses from the offshore people would almost always take until the next day. The people we hired were great workers, but we couldn't simply hand off tasks to them at the end of the day. An effective hand off would require a lengthy real-time conversation about the details. No matter how many times I brought it up, our upper management never seemed to understand that software development is not the same as assembly line work. You can't simply hand everything off at the end of your shift.

Ah, that beginning section triggered some memories. :) At our uni, we had a powerful computing machine able to handle many dozens of terminals at once, backed by a full megabyte of core memory which we could physically watch operating. 32 32k "pages" of 160•256 little magnetic cores, each page the size of a wide door, all neatly jointed to a whole wall of wiring cabinet leading to the processor unit, so you could physically inspect and repair them by just flipping through. It had ten bits per byte! Eight bits per actual data byte, and two more for parity so that a stuck bit could be not only detected but fixed, transparently to the running program because the error correction system was running separate from the computer, one on each memory page. When we were shown this marvel of technology, the presenting professor demonstrated the incredible resilience of this type of memory architecture by taking out a ball pen, physically opening a memory page on the wall that was the memory, and running his pen over the cores to randomly flip some. We were awestruck. And then people started flooding in because their programs had crashed, some after days of runtime. We were slightly less awestruck afterwards. ;) Turned out you needed to use a non-conducting piece of wood or plastic for the demonstration, the metal pen had hit not just cores but also shorted wire crossings, flipping other bits elsewhere (including their parities) and thus causing some real memory corruption. Unfortunately, the professor had killed not some single unlucky program but a crucial part of the operating system which then took all the programs with it. Booting everything up again took several days. We were the last freshmen group to ever be demonstrated our computer's memory resilience mechanism.

Perfect explanation of something I've had to communicate to management too many times in IT over the past 30 years. I was once offered an entire team to do something in one month, and I told them it would take a year, regardless. They gave the project to another senior engineer, and it didn't take a year; It took a year and a half.

The biggest point of confusion which still percolates all businesses today: Humans are NOT resources, yet we're supposed to behave as if we're are resources for the higher-ups

"You're a dial up connection I'm a gigabit lan. I'm a mythical man month you're a one minute man" - Monzy

There's also Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

It's not just team intercommunication. You are forgetting the managerial overhead - the push to have so many subordinates, middle managers, more middle managers.... limit their staff count (unless more levels of managers are inserted), etc. "Oh you can't possibly manager more than N people because we'd have to give you a pay raise.... we now have to get another manager..." An entire push for more people that's got nothing to do with solving the programming problem. Managers managing managers. The curve does indeed start to climb again as overhead becomes THE issue.

If there was a Disney movie this man would be the voice of a great old knight who tells his grand kids about his advantures when he sailed the seven C s, how it took him one Swift Go with his sword (which was all Rust) to fight a giant Python. And he would tell how he collected a valuable Ruby and the Elixir of life from an island called Java. He didn't have a Basic life at all. He would tell the story how he fell in love with Julia and that they used to play Dart and had some Smalltalk. So quickly he put a Ring on her finger and they got married. His old friend Pascal did the ceremony. Professor Brailsford is my favourite Computerfile story teller 😀

I had the privilege of taking "A Personal History of Computing" from Professor Brooks when I was a university student (probably 2013, but I don't remember for sure). It was basically an hour of him telling stories of his life every Friday for a semester. I wish I could remember more than I do, but I do remember that a lot of it was fascinating to hear!

One project I worked on was exactly like the last hypothetical in this video. We (the developers) knew that the project was a MINIMUM of 2 years, but a new manager came in and said he wanted it done in 9 months (Strange coincidence). We told him in meetings that it was a guaranteed 2-year project (because we had done the exact same project several years earlier and it was a 2-year project). This wasn't our first rodeo. Well, lo and behold, the project was 15 months late (and 15 months over budget) because the managing director wouldn't listen to the developers who had the experience. He tried to throw money at the problem in bonuses and OT, but it was a 2-year project and no amount of money or more people was going to shorten it. We knew it, and he eventually was removed from the project when it was already 6 months late and executive management interviewed the developers. Luckily, the executive team trusted our answers in the RCA. However, almost all of us had left by then because of the unreasonable work environment. I stayed on part-time to KT as much as I could to the new guys. The product did ship, and it shipped nearly on the 2-year end date we as a development team had forecast.

"Adding more manpower to a late project makes it more late"

To calculate the duration of a project, estimate how long it will take, double it, and move to the next highest unit. Thus a 2 week task will take four months.

I wonder if most young engineering organizations are familiar with this. When I was starting 25 years ago this was one of the major engineering process books. The tech in the book itself was already pretty old but the "Mythical Man Month" was a standard concept. Of course back then we actually used books. They had a lot of info, but the problem was we had to pay $40+ for everything. Sometimes they came with disks or CDs!