1 00:00:00,000 --> 00:00:04,480 Today i want to talk about "The Mythical Man Month". It's written by a guy 2 00:00:04,480 --> 00:00:10,639 called Fred Brooks who was part of the IBM New York team in the ... I guess he must 3 00:00:10,639 --> 00:00:16,240 have started in the 50s, moving on into the 60s. And this was the era of IBM 4 00:00:16,240 --> 00:00:21,119 wanting to step beyond architectures that absolutely needed to 5 00:00:21,119 --> 00:00:26,640 be programmed in assembler. They wanted a paradigm shift in writing Operating 6 00:00:26,640 --> 00:00:30,480 Systems - although they still ended up using assembler for that. 7 00:00:30,480 --> 00:00:35,760 They wanted higher-level languages. They wanted a big leap forward and their 360 8 00:00:35,760 --> 00:00:40,640 series did give us several big leaps forward, there is no question about it. 9 00:00:40,640 --> 00:00:45,840 The Mythical Man Month is a myth, because unless you are very very lucky, and it 10 00:00:45,840 --> 00:00:52,640 only happens occasionally, men and months are not interchangeable. 11 00:00:52,640 --> 00:00:58,320 Now since it was first written, getting on for 45 years 12 00:00:58,320 --> 00:01:03,840 ago now, in 1975, I'm afraid there's no chance of getting it called a 13 00:01:03,840 --> 00:01:08,720 "person month" or anything like that. So I am only following the actuality and I'm 14 00:01:08,720 --> 00:01:13,119 afraid that some of the graphs I draw will have "Men vs Months" but if you 15 00:01:13,119 --> 00:01:18,640 want to put "person-power" down there [that's] absolutely fine. 16 00:01:18,640 --> 00:01:22,880 The era that you've got to project yourself back into - which is a lot easier for me than 17 00:01:22,880 --> 00:01:28,400 for many of you - is the 1960s and there was 18 00:01:28,400 --> 00:01:33,600 a really awkward situation that the basics of computer hardware, at least, 19 00:01:33,600 --> 00:01:39,600 were understood >> IBM promo video: "IBM computers solve in minutes problems that once took weeks, 20 00:01:39,600 --> 00:01:44,720 months even years" >> DFB: And what was understood was that having more memory 21 00:01:44,720 --> 00:01:52,079 cost a lot of money! In a previous video ["Meg in a box"] I pointed out - and two IBM salesman came 22 00:01:52,079 --> 00:01:58,960 buttoned up, holding ... [ a Meg in a Box ] that one Megabyte of IBM memory 23 00:01:58,960 --> 00:02:04,960 for the 360 series - which came as a Meg in a Box for demonstration purposes but 24 00:02:04,960 --> 00:02:10,720 could be supplied in a more chassis-mountable format later - that one Megabyte 25 00:02:10,720 --> 00:02:18,160 would have cost you $100,000. Now, Fred [Brooks] was the leader of the team that 26 00:02:18,160 --> 00:02:25,280 had not only got to specify the hardware - was it going to be 6-bit characters? - 27 00:02:25,280 --> 00:02:29,920 how much maximum memory could you have, and all that. They not only were going to 28 00:02:29,920 --> 00:02:34,640 specify the hardware, they were also going to try and move on 29 00:02:34,640 --> 00:02:39,519 from that to writing an operating system. Because they realized that this was 30 00:02:39,519 --> 00:02:44,640 classic 60s situation Even IBM customers won't be able to 31 00:02:44,640 --> 00:02:50,080 afford to buy - let alone air-condition - one of these mainframes per programmer. 32 00:02:50,080 --> 00:02:54,800 It's going to be a big, shared, machine, So we're going to have to give value for 33 00:02:54,800 --> 00:03:01,280 money and make sure that it's got a good multi-user multi-tasking operating system. 34 00:03:01,280 --> 00:03:07,360 And there's another major task that has to be taken on. [At the] turn of 1950 to 1960 35 00:03:07,360 --> 00:03:13,040 it's not very long after genuinely First Generation machines 36 00:03:13,040 --> 00:03:16,400 were gradually getting 37 00:03:16,400 --> 00:03:19,200 - how should we say? - outdated. 38 00:03:19,200 --> 00:03:23,519 And think back: EDSAC, 1949, one i'm familiar with 39 00:03:23,519 --> 00:03:30,000 It used basically the [slightly modified] Baudot code. It was 5 bits. 40 00:03:30,000 --> 00:03:35,519 2 ^ 5 is 32. That's not too bad, you [might] say, until you reflect that 41 00:03:35,519 --> 00:03:42,879 for your data you want alphabetics (26) and you want numerics (10) 42 00:03:42,879 --> 00:03:47,760 That's 36 slots gone already! How do you get over it? Well, you have [to use] what's called 43 00:03:47,760 --> 00:03:53,599 a shift character. This is still here on keyboards (or simulated keyboards) we use today. 44 00:03:53,599 --> 00:03:59,120 All of this was a known factor and the pressure then, on all [computer] architects was 45 00:03:59,120 --> 00:04:04,560 was; "Shall we make a tentative step forward? How about going for 6 bits?" 46 00:04:04,560 --> 00:04:09,920 And in, how should I say, group discussions within 47 00:04:09,920 --> 00:04:15,680 ICL, within Burroughs, within every other IBM competitor: 48 00:04:15,680 --> 00:04:20,799 "Ooh! An extra bit?! Oh! that's going to cost a fortune! Will our customers 49 00:04:20,799 --> 00:04:26,160 pay for that?" Because, you know, adding that [extra bit] onto every single location, Oh! it 50 00:04:26,160 --> 00:04:29,919 doesn't bear thinking about! Yes i think we ... if if we price it carefully ... we can 51 00:04:29,919 --> 00:04:33,199 get away with 6 bits". And certainly, 52 00:04:33,199 --> 00:04:37,680 again, some of you may remember, I think I referred to this earlier: When i came to 53 00:04:37,680 --> 00:04:44,080 [Univ. of ] Nottingham we were stuck with a 6-bits per character compute:r The ICL 1900 series. 54 00:04:44,080 --> 00:04:48,960 It had 6-bit characters and you could pack 55 00:04:48,960 --> 00:04:54,400 4 of them into a word, which might be able to hold a biggish integer, 56 00:04:54,400 --> 00:05:00,320 although 24 bits isn't very big, so to get even bigger 57 00:05:00,320 --> 00:05:04,479 agglomerations you had to, as it were, 58 00:05:04,479 --> 00:05:08,720 electronically link two of these [say] together. By the time you got to 48-bit 59 00:05:08,720 --> 00:05:12,400 words you were getting to a stage that at least you could do 60 00:05:12,400 --> 00:05:17,039 single precision arithmetic almost accurately enough to keep an 61 00:05:17,039 --> 00:05:22,479 engineer happy. If you look up, as i have had to do, the details about Fred [Brooks] ... by the 62 00:05:22,479 --> 00:05:26,720 way he's aged in his early 90s and for those of you who are going to 63 00:05:26,720 --> 00:05:30,800 make sarcastic comments in the Comments [of this video] "No, I haven't met him; I'd love to meet 64 00:05:30,800 --> 00:05:35,520 him, I really would. It would be, y'know, a great treat and a great privilege. 65 00:05:35,520 --> 00:05:41,360 But Fred, a leader of the team who had been [ a staff member] on earlier IBM 6-bit 66 00:05:41,360 --> 00:05:44,080 machines -- but not going to have the power and 67 00:05:44,080 --> 00:05:50,000 penetration of this new-planned series. He said: "No! No! no! no! - really 6 bits is not 68 00:05:50,000 --> 00:05:52,479 is not enough!" 69 00:05:52,479 --> 00:05:55,919 OK - You can do the alphabet, but you can't 70 00:05:55,919 --> 00:06:00,319 do the alphabet in upper and lower case which is what we want. We increasingly 71 00:06:00,319 --> 00:06:04,639 want to be able to typeset stuff, so we need to be able to distinguish between 72 00:06:04,639 --> 00:06:09,520 lowercase 'g' and uppercase 'G' and they really ought to have codes of 73 00:06:09,520 --> 00:06:15,199 their own! And when you tot it up, numbers uppercase, lowercase some punctuation 74 00:06:15,199 --> 00:06:18,880 2^6 = 64; it's not quite big enough obviously 75 00:06:18,880 --> 00:06:23,039 all hardware people know it's unthinkable to have a hardware 76 00:06:23,039 --> 00:06:27,280 byte that is actually an odd number of bits. 77 00:06:27,280 --> 00:06:31,520 "That way does madness lie" [King Lear: Shakespeare] 78 00:06:31,520 --> 00:06:38,240 But we have got to be brave here! Let's go for the 8-bit byte. And, of course, a byte 79 00:06:38,240 --> 00:06:43,199 meant, in those days, any agglomeration of bits that your machine deemed to be 80 00:06:43,199 --> 00:06:47,600 worthy of holding a character. And i can just imagine [the team meetings]: 81 00:06:47,600 --> 00:06:52,080 "Fred, you know, have you gone completely off your rocker, y' know. have you any 82 00:06:52,080 --> 00:06:56,479 idea how much this will cost ?!" And i think that my retort would have been: "Well, look 83 00:06:56,479 --> 00:07:00,319 they are IBM customers, and they know they're getting the best!". This isn't 84 00:07:00,319 --> 00:07:06,720 any memory this is **IBM memory** !! And, in a way, I can see that if anybody was going 85 00:07:06,720 --> 00:07:10,319 to pioneer and do this it had better be IBM, 86 00:07:10,319 --> 00:07:13,199 because they had customers that could afford 87 00:07:13,199 --> 00:07:17,440 to be alpha testers on this idea for them and to report back whether it was a 88 00:07:17,440 --> 00:07:22,080 good idea or not. To shorten the story somewhat they did go for the 8-bit bytes 89 00:07:22,080 --> 00:07:25,599 but also what came along with that and i don't know, again, if it was 90 00:07:25,599 --> 00:07:28,960 somebody else on the team, or whether it was Fred \{Brooks], or whatever, 91 00:07:28,960 --> 00:07:35,039 also came up with the idea of ... as follows: there'll be a temptation 92 00:07:35,039 --> 00:07:39,680 to put in or make possible an agglomeration of 93 00:07:39,680 --> 00:07:45,120 four of these eight bit entities that's 32 bits that will hold a very decent 94 00:07:45,120 --> 00:07:50,639 size integer indeed because, on a 6-bit machine, 95 00:07:50,639 --> 00:07:57,520 digging out each 6-bit character from a 24-bit agglomeration ... Oh! it makes me shiver 96 00:07:57,520 --> 00:08:02,560 to think about it. You needed bit-shift operators; you needed to shift left the 97 00:08:02,560 --> 00:08:08,319 six bits on the left into a vacant word as it was, 24-bit word. and then shift 98 00:08:08,319 --> 00:08:13,120 them back again and throw away the other stuff. Or do whatever. And somebody on 99 00:08:13,120 --> 00:08:18,720 that IBM team said "No! we make the bytes be addressable!". 100 00:08:18,720 --> 00:08:22,960 But had I been the chief hardware man I'd probably have had 50 fits because you are 101 00:08:22,960 --> 00:08:28,000 making the address bus be that much wider. Yeah! 102 00:08:28,000 --> 00:08:31,919 you're basically saying: "No. it's not y'know ... 103 00:08:31,919 --> 00:08:36,560 i'm not pointing at one big thing i'm pointing at lots of smaller things individually." 104 00:08:36,560 --> 00:08:41,120 However, of course, Fred [Brooks] would say: "Yes but once you've landed on 105 00:08:41,120 --> 00:08:45,920 that thing and don't forget a lot of our programmers and a lot of our customers 106 00:08:45,920 --> 00:08:50,320 use COBOL and we if we make our *characters* be 107 00:08:50,320 --> 00:08:54,480 8 bits then all our character-based programming on which 108 00:08:54,480 --> 00:08:58,560 and from which our bread and butter comes is immediately 109 00:08:58,560 --> 00:09:03,040 probably an order of magnitude faster (almost) than it would be on lesser machines 110 00:09:03,040 --> 00:09:07,519 because we've got the 8-bit addressable byte. So, anyway, he won the 111 00:09:07,519 --> 00:09:12,320 day and I think the the rest is history. Because looking up 112 00:09:12,320 --> 00:09:15,600 his biography now I 113 00:09:15,600 --> 00:09:19,839 was amused around the bottom [of the info.] when people said: "Fred, what are you most proud of? 114 00:09:19,839 --> 00:09:24,560 What was your biggest contribution to 115 00:09:24,560 --> 00:09:29,519 system 360 architecture?" And he didn't say " ... making people aware of 'The Mythical 116 00:09:29,519 --> 00:09:34,000 Man Month'. He said "No - winning the battle that we didn't need a 117 00:09:34,000 --> 00:09:39,120 6-bit byte we needed an 8-bit byte". And I was so glad to see that [written] down there, in 118 00:09:39,120 --> 00:09:43,120 black and white, In a way, [is] the thing we're going to talk about for the latter part 119 00:09:43,120 --> 00:09:47,120 of this talk now. He [Fred] would have regarded - I guess it's a 120 00:09:47,120 --> 00:09:51,920 very nice desirable side effect - he decided in the 121 00:09:51,920 --> 00:09:56,240 1970s to write an account 122 00:09:56,240 --> 00:10:03,279 of "How we did it on the 360", but in a chatty accessible kind of, 123 00:10:03,279 --> 00:10:09,279 storytelling almost, kind of mode. And right at the start and in various 124 00:10:09,279 --> 00:10:14,800 places in this book - do make sure you get the 1995 125 00:10:14,800 --> 00:10:20,079 "20 years after" version, because it's got not only the original [book] reproduced but 126 00:10:20,079 --> 00:10:25,440 it's also got an analysis of "Where I went wrong" says Fred Brooks. Why did he 127 00:10:25,440 --> 00:10:29,360 make his name with that and what was it all about? I have here 128 00:10:29,360 --> 00:10:33,839 a chart. He plots out a task which is typically 129 00:10:33,839 --> 00:10:39,040 reckoned to be nine man-months of labour and he says: "OK let's accept that. [let's] see 130 00:10:39,040 --> 00:10:43,200 what it means: "9 man months". What this means is 131 00:10:43,200 --> 00:10:49,200 that if i put one person on that task it will indeed take them nine months. 132 00:10:49,200 --> 00:10:54,800 If i put two persons on that task then, of course, it'll halve the time won't it ? 133 00:10:54,800 --> 00:10:59,440 It'll only take four and a half months? If i put three people on it, it'll take 134 00:10:59,440 --> 00:11:05,440 one third of the time. It will take three man-months and so on and so on. Until the 135 00:11:05,440 --> 00:11:11,040 limit point comes that if I could only afford 9 programmers to put onto this 136 00:11:11,040 --> 00:11:17,360 task it will all be done in one month? "Stop!", he says, "that is an idealized 137 00:11:17,360 --> 00:11:22,720 situation, almost never realized in practice, because it assumes that your 138 00:11:22,720 --> 00:11:28,720 nine people do not have a need to communicate with each other. 139 00:11:28,720 --> 00:11:34,399 [and] that these tasks are truly separable and in parallel. A bit like picking tomatoes 140 00:11:34,399 --> 00:11:40,000 or strawberries or something like that. You have your own patch, you don't bump 141 00:11:40,000 --> 00:11:44,240 into anybody else. You can pick independently of all the other pickers 142 00:11:44,240 --> 00:11:48,800 in the vegetable field - something like that. And he said this very very rarely 143 00:11:48,800 --> 00:11:55,200 happens it just isn't like that The situations in the layer below you, in 144 00:11:55,200 --> 00:11:59,279 the hardware, where you can get genuine parallelism 145 00:11:59,279 --> 00:12:04,000 like that, like fetching bits in parallel. Since those bits are on separate wires 146 00:12:04,000 --> 00:12:09,600 and don't interfere then, yes, this sort of argument [is OK], but when it's real people 147 00:12:09,600 --> 00:12:13,279 who need to consult then it goes more like this. 148 00:12:13,279 --> 00:12:18,240 First, he said, let's take a look at the absolute polar opposite [from] everything 149 00:12:18,240 --> 00:12:21,839 being separated and everybody can do their own thing. I do believe that this 150 00:12:21,839 --> 00:12:26,480 thing that is now on my left [a graph]. I think it's a rectangular hyperbola because the 151 00:12:26,480 --> 00:12:32,560 product of the x and the y numbers [values] yields a constant number as it were. 152 00:12:32,560 --> 00:12:36,880 9 times one is 9; 3three times 3 is 9 and so on. He then points out, he 153 00:12:36,880 --> 00:12:40,880 says your worst nightmare is 154 00:12:40,880 --> 00:12:45,600 to take on 9 people in order to get a 9-fold increase, you hope. 155 00:12:45,600 --> 00:12:50,800 But unfortunately your underlying task is not 156 00:12:50,800 --> 00:12:55,120 fully and independently partitionable. It's one of these horrid things where 157 00:12:55,120 --> 00:12:57,839 the person who does a little bit at the beginning 158 00:12:57,839 --> 00:13:03,200 and says: "Oh! that's my month [done] now. I want my money!", has to hand over the state of 159 00:13:03,200 --> 00:13:07,519 his calculation to the next person along and you say: "Well, why can't that 160 00:13:07,519 --> 00:13:12,320 person hand it over earlier?" No! no! if it's one of these awful problems where 161 00:13:12,320 --> 00:13:16,880 you have to compute a magic number to be handed on to the next stage you can't 162 00:13:16,880 --> 00:13:21,760 hand it on until you've computed it. So it's pointless hiring nine folks up 163 00:13:21,760 --> 00:13:25,519 front - you're just gonna have to pay them furlough money while they sit there 164 00:13:25,519 --> 00:13:30,480 twiddling their thumbs, because they haven't had the kickstart that their 165 00:13:30,480 --> 00:13:35,680 particular contribution [needs]. so it's like a, you know, a passing on of a token in a 166 00:13:35,680 --> 00:13:40,399 relay race. If you've got a problem that really is like that, it's innately 167 00:13:40,399 --> 00:13:44,560 serial, from start to finish, then you are in deep trouble. You can pour men and 168 00:13:44,560 --> 00:13:48,560 money and material into it until you're blue in the face you won't get it below 169 00:13:48,560 --> 00:13:53,120 [the] 9 months worst possible case. But then he says it's never quite that 170 00:13:53,120 --> 00:13:57,760 bad often. Let's go to intermediate possibilities, 171 00:13:57,760 --> 00:14:02,560 On the next sheet. Now, as you might imagine, all that does is it takes our 172 00:14:02,560 --> 00:14:08,320 previous, perfect, rectangular hyperbola shifts it up a bit. And you can see here 173 00:14:08,320 --> 00:14:11,760 the net result is pretty much what you [might] expect. 174 00:14:11,760 --> 00:14:17,120 You try adding men as fast as you can but it levels off 175 00:14:17,120 --> 00:14:19,199 higher than 176 00:14:19,199 --> 00:14:23,199 being down here, which is the genuine asymptote, where it's headed for the axis. 177 00:14:23,199 --> 00:14:27,120 It doesn't do that - and that's because there's inherent 178 00:14:27,120 --> 00:14:32,560 enough inherent serial communication there to shove the curve up a bit and 179 00:14:32,560 --> 00:14:37,199 you can't do any better than that. So, that would be the case for, if you like, 180 00:14:37,199 --> 00:14:40,720 an average program that a team might write with 181 00:14:40,720 --> 00:14:45,360 some intra-team communication. 182 00:14:45,360 --> 00:14:49,360 If you get unlucky and you get a task 183 00:14:49,360 --> 00:14:54,720 that has got more complex communication you've still got time up here, you still 184 00:14:54,720 --> 00:14:59,120 get men along here but - can you see what's happening now - 185 00:14:59,120 --> 00:15:02,639 that little curve I've drawn there is trying 186 00:15:02,639 --> 00:15:06,959 to get more and more like a flat straight line at the top. 187 00:15:06,959 --> 00:15:10,079 You remember the diagram before last? 188 00:15:10,079 --> 00:15:14,639 There's still enough parallelism in there that it doesn't quite flatten 189 00:15:14,639 --> 00:15:17,600 itself out into a straight line, but you can see what happens. 190 00:15:17,600 --> 00:15:22,399 You get some improvement [with added people] and then you get none at all and you just head up 191 00:15:22,399 --> 00:15:26,800 towards the inevitable: it's nine man months whether you like it or not! 192 00:15:26,800 --> 00:15:30,079 So a task with complex intercommunications 193 00:15:30,079 --> 00:15:33,040 can have a curve looking something like that 194 00:15:33,040 --> 00:15:39,600 and what he [Fred Brooks] said was that you really must bear this in mind all the time. It's no 195 00:15:39,600 --> 00:15:43,360 use talking about men and months as if they're 196 00:15:43,360 --> 00:15:46,800 interchangeable and "trade off-able", they're not! >> Sean: One of the things i thought 197 00:15:46,800 --> 00:15:49,759 when i saw this is then there's the other thing that you've got to have 198 00:15:49,759 --> 00:15:54,240 "the handover" right yes that's right this person has to explain what's going on to 199 00:15:54,240 --> 00:15:59,199 the second person. >> DFB: that's exactly right Sean! And i think he [Fred B.] more or less in 200 00:15:59,199 --> 00:16:05,040 different words says that this is another thing about adding manpower to a 201 00:16:05,040 --> 00:16:10,959 project, particularly late on. You spend so much time explaining to the newcomers, 202 00:16:10,959 --> 00:16:16,399 who are quite talented, just why this intricate structure was necessary, before 203 00:16:16,399 --> 00:16:19,839 they could even start any programming that you'd have been better off not to 204 00:16:19,839 --> 00:16:22,880 take them on at all And so there are various homilies in 205 00:16:22,880 --> 00:16:27,360 here, which say: "If you think you are underpowered on a project try and 206 00:16:27,360 --> 00:16:33,440 realize it early. You can probably rescue the situation with more men and whatever 207 00:16:33,440 --> 00:16:38,639 if you recognize it early enough and take drastic action. But don't leave it 208 00:16:38,639 --> 00:16:42,720 until it's one month away from delivery time and then have a panic and [start] saying: 209 00:16:42,720 --> 00:16:48,639 "Omigod there's [still] a year's work to go!" You know memorable phrase number 2 : 210 00:16:48,639 --> 00:16:53,040 "How did this project get to be a year late?!" 211 00:16:53,040 --> 00:16:58,560 says the big boss. And the answer is: "One day at a time"