This book launched research in project management, software development and deserves to be read with respect. Its image of the Tar Pits, so fatal to so many has stood the test of 25+ years. See if you can imagine the world programmed in cards, where physical damage or disorder of the software source code was not only possible, but likely. Visit the world of massive system programming in the early 60s. Life is better today in many ways, often due to the publication of this book.
Also: MythicalManMonthAnniversaryEdition 1995 Contains the "No Silver Bullet" essay
--BobLee July, 2002
A good review by ScottRosenberg?: HTTP://www.wordyard.com/2006/10/02/mythical-man-month/
Read now it seems to hold many XP-like values:
There are some great, timeless observations in TheMythicalManMonth that work independent of the particular practice, implementation, or label (meaning you can get some leverage with the ideas without having to invoke "XP" - useful tactic when dealing with a backlash.)
As a certified old guy (I have been told so, by certain of the present generation of software whipper-snappers) sometimes I find myself a bit tired with phrases like: "XP like values." No. The values are good because they make sense. XP embodies a lot of things that make sense. As does TheMythicalManMonth, and occasionally other stuff too. The useful values are methodology agnostic. Methodologies embrace them or not (most don't). The values don't care. -- JamesBullock
Hear, hear. See Ecclesiastes 1:10, also take a squint at http://www.cet.sunderland.ac.uk/webedit/allweb/news/wrong.ppt, the slides for a talk on agility I gave at U. Sunderland (sorry it's powerpoint, watch the slideshow to get full value). Even Royce's original waterfall paper contains some "XP like values." --KeithBraithwaite
Interesting slides. I wish I'd been around for the talk. I particularly like your list of engineering and manufacturing techniques with "agile" mindset. I've worked in product engineering (hardware & embedded software), manufacturing engineering (discrete and continuous), and R & D. I think we in software could leverage a great deal of technique from what they do if we'd pay attention to what they actually do, vs. some imagined set of bad practices.
One thing engineers of non-software seem to have is an appreciation for their process models. You'll get in just as much trouble for using a model when it has broken down, as for not using a model when it applies. In non-software engineering, you will literally get in trouble for applying a model with inappropriate scope, in either direction. In software engineering we seem to get pretty tangled up in universal solutions, usually after some period when we've been tangled up in NIH, and "no models need apply." - I don't know why.
Keith, it sounds like your work is very similar to what I did back at Carrier corporation, in 1985 to 1989. Subject to the limitations of the tools at the time, we were pretty damn agile as that is currently described, and within a couple practices of full blown XP. Then at GE we actually did "agile" database modeling as described in Fowler's recent paper. (I'm still mulling over whether to post that as a case study to the agile modeling list.) These good, powerful ideas are old, and well known if you know where to look. At both Carrier and GE we stole the practices that are now the focus of such noise and passion, from some very unlikely sources. - jb
Interesting. To research that talk I went back to the proceedings of the two original "software engineering" conferences. Heart-breaking stuff: you have the big names of the times, Dijkstra and such, saying all the right things, intermingle activities, collaborate with the customer, emphasise testing etc. etc. but then they always seem to lose the plot and say something like "such-and-so is obviously the solution, but of course we ought to do this-and-that" and it all goes very wrong. The "agile" ideas are all around, and have been well known for a long long time, but they need searching for.
I've been poking at how it goes sadly wrong for quite a while. Unfortunately, I have only a vague notion that it's got a lot to do with feedback, and a lot to do with having real outputs that are really measured. Yet that path is fraught with risk. The references on how to steer knowledge work are more Deming, Goldratt, Austin & Argyris than others. Big methodologies with everything specified appeal to the org-bots and admini-drones among us. - JB
Meanwhile, one of the audience at Sunderland had worked with Royce at TRW when the process described in the "waterfall" paper was developed. Since, I maintain, this is the exact origin of the software engineering mind-set as usually expressed, it's interesting to have this bit of background: the reason that Royce developed that method was to build a framework within which some time-served hacks who were basically incompetent (but who couldn't be disposed of for various reasons) could be constrained to deliver any value at all. The skillful developers didn't use the method because they didn't need it. Thus the foundation was laid for our industry to be conditioned to think of as "best practice" that which was merely a way to prevent idiots causing damange. --KB
Sadly, as Joel Spolsky points in out in http://www.joelonsoftware.com/articles/fog0000000024.html, large numbers of very large organisations want exactly that from a methodology. If you're willing to promise them a process that guarantees quality work no matter who sits behind the keyboard then you'll get their business.--AO
This is Taylor style "scientific management", which has it's appeal, and even it's relevance in the right domains. The useful question is which domains are appropriate for this style of management. I'm suspicious that there's a continuom of optimal trade offs between repeatability and adaptability even dealing with software. Conversion or remediation of a large-scale portfolio seems to me to be a high-repeatability application. Coding of piles of business processes within an ERP package seems somewhat less repeatable. Creating novel systems software seems to need much more adaptability, but you've still got to ship. I am suspicious that the methodology arguments stem in part from addressing several problems as if they all had one common solution. - JB
Repeatability is the key. Even the "real" engineering disceplines tend to fall over in direct proportion to the novelty of what they are doing (more on this coming...). --KB
Two handles the non-software engineering disciplines have I think, are the clear distinction between research, development, and production, and the distinction between product and process engineering. These are distinctions we don't make clearly in software. Research is almost a "defined investment" activity. You spend a bunch of money in a domain for a while, and you get what you get. "Hey we just proved that this kind of adaptive defrost algorithm works, and saves energy." Development, as in product development, is more like a defined problem but not a defined solution. Production - building heat pumps with the new defrost, once it's been designed and piloted - is pretty repeatable.
The way you treat exceptions is also different among research, development, and production. In research an exception is something interesting to investigate. In development it's a problem to solve. In production it's an error, and you route it out of the repeatable process.
Software is almost like development engineering all the time. Interesting to me, we tend to borrow metaphors from research (the developers do) and manufacturing (some managers do) vs. development, which as I said, seems the better fit. Humans abhor the middle way, it seems. We also tend to get stuck in one set of expectations or another, not easily switching modes, to "production" when we're remediating a pile of code, or "research" when it's time to build something unlike what's ever been built before.
The non-software disciplines "fall down" in the sense that their research and development activities aren't very repeatable. I'm not sure if that counts as failure. The big question is how to keep the admini-drones at bay when you're doing research or doing development. One technique I've used is to talk in terms of what we don't know. That only works some of the time. Sometimes it makes them nuts, and you just get fired. Then the next guy who knows no more than you do but keeps quiet about it, shows up and fails to deliver. But he gets paid in the meanwhile.
Lie to me. I promise I'll believe. from "Strong Enough" by Cheryl Crow.
This article: http://www.firstmonday.dk/issues/issue4_10/bezroukov/index.html discusses Open Source Development as a Special Case of Applied Science. "A Special Case of Applied Science" is a very interesting model for software development. Fits with the research, design, manufacturing frame above.
-- jb
BTW, How "ought" I to format the above? Requesting guidance. - jb
The talk, by the way, will be repeated some time in autumn 2003 at the Univeristy of Westminster. --KB
I'm on the wrong continent, unfortunately. But stranger things have happened. - JB
![[Home]](/wiki.gif)