Today i want to talk about "The Mythical Man Month". It's written by a guy
called Fred Brooks who was part of the IBM New York team in the ... I guess he must
have started in the 50s, moving on into the 60s. And this was the era of IBM
wanting to step beyond architectures that absolutely needed to
be programmed in assembler. They wanted a paradigm shift in writing Operating
Systems - although they still ended up using assembler for that.
They wanted higher-level languages. They wanted a big leap forward and their 360
series did give us several big leaps forward, there is no question about it.
The Mythical Man Month is a myth, because unless you are very very lucky, and it
only happens occasionally, men and months are not interchangeable.
Now since it was first written, getting on for 45 years
ago now, in 1975, I'm afraid there's no chance of getting it called a
"person month" or anything like that. So I am only following the actuality and I'm
afraid that some of the graphs I draw will have "Men vs Months" but if you
want to put "person-power" down there [that's] absolutely fine.
The era that you've got to project yourself back into - which is a lot easier for me than
for many of you - is the 1960s and there was
a really awkward situation that the basics of computer hardware, at least,
were understood >> IBM promo video: "IBM computers solve in minutes problems that once took weeks,
months even years" >> DFB: And what was understood was that having more memory
cost a lot of money! In a previous video ["Meg in a box"] I pointed out - and two IBM salesman came
buttoned up, holding ... [ a Meg in a Box ] that one Megabyte of IBM memory
for the 360 series - which came as a Meg in a Box for demonstration purposes but
could be supplied in a more chassis-mountable format later - that one Megabyte
would have cost you $100,000. Now, Fred [Brooks] was the leader of the team that
had not only got to specify the hardware - was it going to be 6-bit characters? -
how much maximum memory could you have, and all that. They not only were going to
specify the hardware, they were also going to try and move on
from that to writing an operating system. Because they realized that this was
classic 60s situation Even IBM customers won't be able to
afford to buy - let alone air-condition - one of these mainframes per programmer.
It's going to be a big, shared, machine, So we're going to have to give value for
money and make sure that it's got a good multi-user multi-tasking operating system.
And there's another major task that has to be taken on. [At the] turn of 1950 to 1960
it's not very long after genuinely First Generation machines
were gradually getting
- how should we say? - outdated.
And think back: EDSAC, 1949, one i'm familiar with
It used basically the [slightly modified] Baudot code. It was 5 bits.
2 ^ 5 is 32. That's not too bad, you [might] say, until you reflect that
for your data you want alphabetics (26) and you want numerics (10)
That's 36 slots gone already! How do you get over it? Well, you have [to use] what's called
a shift character. This is still here on keyboards (or simulated keyboards) we use today.
All of this was a known factor and the pressure then, on all [computer] architects was
was; "Shall we make a tentative step forward? How about going for 6 bits?"
And in, how should I say, group discussions within
ICL, within Burroughs, within every other IBM competitor:
"Ooh! An extra bit?! Oh! that's going to cost a fortune! Will our customers
pay for that?" Because, you know, adding that [extra bit] onto every single location, Oh! it
doesn't bear thinking about! Yes i think we ... if if we price it carefully ... we can
get away with 6 bits". And certainly,
again, some of you may remember, I think I referred to this earlier: When i came to
[Univ. of ] Nottingham we were stuck with a 6-bits per character compute:r The ICL 1900 series.
It had 6-bit characters and you could pack
4 of them into a word, which might be able to hold a biggish integer,
although 24 bits isn't very big, so to get even bigger
agglomerations you had to, as it were,
electronically link two of these [say] together. By the time you got to 48-bit
words you were getting to a stage that at least you could do
single precision arithmetic almost accurately enough to keep an
engineer happy. If you look up, as i have had to do, the details about Fred [Brooks] ... by the
way he's aged in his early 90s and for those of you who are going to
make sarcastic comments in the Comments [of this video] "No, I haven't met him; I'd love to meet
him, I really would. It would be, y'know, a great treat and a great privilege.
But Fred, a leader of the team who had been [ a staff member] on earlier IBM 6-bit
machines -- but not going to have the power and
penetration of this new-planned series. He said: "No! No! no! no! - really 6 bits is not
is not enough!"
OK - You can do the alphabet, but you can't
do the alphabet in upper and lower case which is what we want. We increasingly
want to be able to typeset stuff, so we need to be able to distinguish between
lowercase 'g' and uppercase 'G' and they really ought to have codes of
their own! And when you tot it up, numbers uppercase, lowercase some punctuation
2^6 = 64; it's not quite big enough obviously
all hardware people know it's unthinkable to have a hardware
byte that is actually an odd number of bits.
"That way does madness lie" [King Lear: Shakespeare]
But we have got to be brave here! Let's go for the 8-bit byte. And, of course, a byte
meant, in those days, any agglomeration of bits that your machine deemed to be
worthy of holding a character. And i can just imagine [the team meetings]:
"Fred, you know, have you gone completely off your rocker, y' know. have you any
idea how much this will cost ?!" And i think that my retort would have been: "Well, look
they are IBM customers, and they know they're getting the best!". This isn't
any memory this is **IBM memory** !! And, in a way, I can see that if anybody was going
to pioneer and do this it had better be IBM,
because they had customers that could afford
to be alpha testers on this idea for them and to report back whether it was a
good idea or not. To shorten the story somewhat they did go for the 8-bit bytes
but also what came along with that and i don't know, again, if it was
somebody else on the team, or whether it was Fred \{Brooks], or whatever,
also came up with the idea of ... as follows: there'll be a temptation
to put in or make possible an agglomeration of
four of these eight bit entities that's 32 bits that will hold a very decent
size integer indeed because, on a 6-bit machine,
digging out each 6-bit character from a 24-bit agglomeration ... Oh! it makes me shiver
to think about it. You needed bit-shift operators; you needed to shift left the
six bits on the left into a vacant word as it was, 24-bit word. and then shift
them back again and throw away the other stuff. Or do whatever. And somebody on
that IBM team said "No! we make the bytes be addressable!".
But had I been the chief hardware man I'd probably have had 50 fits because you are
making the address bus be that much wider. Yeah!
you're basically saying: "No. it's not y'know ...
i'm not pointing at one big thing i'm pointing at lots of smaller things individually."
However, of course, Fred [Brooks] would say: "Yes but once you've landed on
that thing and don't forget a lot of our programmers and a lot of our customers
use COBOL and we if we make our *characters* be
8 bits then all our character-based programming on which
and from which our bread and butter comes is immediately
probably an order of magnitude faster (almost) than it would be on lesser machines
because we've got the 8-bit addressable byte. So, anyway, he won the
day and I think the the rest is history. Because looking up
his biography now I
was amused around the bottom [of the info.] when people said: "Fred, what are you most proud of?
What was your biggest contribution to
system 360 architecture?" And he didn't say " ... making people aware of 'The Mythical
Man Month'. He said "No - winning the battle that we didn't need a
6-bit byte we needed an 8-bit byte". And I was so glad to see that [written] down there, in
black and white, In a way, [is] the thing we're going to talk about for the latter part
of this talk now. He [Fred] would have regarded - I guess it's a
very nice desirable side effect - he decided in the
1970s to write an account
of "How we did it on the 360", but in a chatty accessible kind of,
storytelling almost, kind of mode. And right at the start and in various
places in this book - do make sure you get the 1995
"20 years after" version, because it's got not only the original [book] reproduced but
it's also got an analysis of "Where I went wrong" says Fred Brooks. Why did he
make his name with that and what was it all about? I have here
a chart. He plots out a task which is typically
reckoned to be nine man-months of labour and he says: "OK let's accept that. [let's] see
what it means: "9 man months". What this means is
that if i put one person on that task it will indeed take them nine months.
If i put two persons on that task then, of course, it'll halve the time won't it ?
It'll only take four and a half months? If i put three people on it, it'll take
one third of the time. It will take three man-months and so on and so on. Until the
limit point comes that if I could only afford 9 programmers to put onto this
task it will all be done in one month? "Stop!", he says, "that is an idealized
situation, almost never realized in practice, because it assumes that your
nine people do not have a need to communicate with each other.
[and] that these tasks are truly separable and in parallel. A bit like picking tomatoes
or strawberries or something like that. You have your own patch, you don't bump
into anybody else. You can pick independently of all the other pickers
in the vegetable field - something like that. And he said this very very rarely
happens it just isn't like that The situations in the layer below you, in
the hardware, where you can get genuine parallelism
like that, like fetching bits in parallel. Since those bits are on separate wires
and don't interfere then, yes, this sort of argument [is OK], but when it's real people
who need to consult then it goes more like this.
First, he said, let's take a look at the absolute polar opposite [from] everything
being separated and everybody can do their own thing. I do believe that this
thing that is now on my left [a graph]. I think it's a rectangular hyperbola because the
product of the x and the y numbers [values] yields a constant number as it were.
9 times one is 9; 3three times 3 is 9 and so on. He then points out, he
says your worst nightmare is
to take on 9 people in order to get a 9-fold increase, you hope.
But unfortunately your underlying task is not
fully and independently partitionable. It's one of these horrid things where
the person who does a little bit at the beginning
and says: "Oh! that's my month [done] now. I want my money!", has to hand over the state of
his calculation to the next person along and you say: "Well, why can't that
person hand it over earlier?" No! no! if it's one of these awful problems where
you have to compute a magic number to be handed on to the next stage you can't
hand it on until you've computed it. So it's pointless hiring nine folks up
front - you're just gonna have to pay them furlough money while they sit there
twiddling their thumbs, because they haven't had the kickstart that their
particular contribution [needs]. so it's like a, you know, a passing on of a token in a
relay race. If you've got a problem that really is like that, it's innately
serial, from start to finish, then you are in deep trouble. You can pour men and
money and material into it until you're blue in the face you won't get it below
[the] 9 months worst possible case. But then he says it's never quite that
bad often. Let's go to intermediate possibilities,
On the next sheet. Now, as you might imagine, all that does is it takes our
previous, perfect, rectangular hyperbola shifts it up a bit. And you can see here
the net result is pretty much what you [might] expect.
You try adding men as fast as you can but it levels off
higher than
being down here, which is the genuine asymptote, where it's headed for the axis.
It doesn't do that - and that's because there's inherent
enough inherent serial communication there to shove the curve up a bit and
you can't do any better than that. So, that would be the case for, if you like,
an average program that a team might write with
some intra-team communication.
If you get unlucky and you get a task
that has got more complex communication you've still got time up here, you still
get men along here but - can you see what's happening now -
that little curve I've drawn there is trying
to get more and more like a flat straight line at the top.
You remember the diagram before last?
There's still enough parallelism in there that it doesn't quite flatten
itself out into a straight line, but you can see what happens.
You get some improvement [with added people] and then you get none at all and you just head up
towards the inevitable: it's nine man months whether you like it or not!
So a task with complex intercommunications
can have a curve looking something like that
and what he [Fred Brooks] said was that you really must bear this in mind all the time. It's no
use talking about men and months as if they're
interchangeable and "trade off-able", they're not! >> Sean: One of the things i thought
when i saw this is then there's the other thing that you've got to have
"the handover" right yes that's right this person has to explain what's going on to
the second person. >> DFB: that's exactly right Sean! And i think he [Fred B.] more or less in
different words says that this is another thing about adding manpower to a
project, particularly late on. You spend so much time explaining to the newcomers,
who are quite talented, just why this intricate structure was necessary, before
they could even start any programming that you'd have been better off not to
take them on at all And so there are various homilies in
here, which say: "If you think you are underpowered on a project try and
realize it early. You can probably rescue the situation with more men and whatever
if you recognize it early enough and take drastic action. But don't leave it
until it's one month away from delivery time and then have a panic and [start] saying:
"Omigod there's [still] a year's work to go!" You know memorable phrase number 2 :
"How did this project get to be a year late?!"
says the big boss. And the answer is: "One day at a time"