At the first keynote of the International Conference on Software Engineering today, Brian Randell reminisced about the 1968 and 1969 NATO conferences that complained about a software crisis and launched the “Software Engineering” term that we have been suffering since. I will summarize my notes from the session later, for now, I want to mention his reference to a talk that Tom Simpson gave in the 1969 Rome conference, which “torpedoed an attempt to create an International Software Engineering Institute”. It’s still a very appropriate talk —I found it online here, and I reproduce it below:
—–
Masterpiece Engineering
T. H. Simpson
You may be interested in an experience I had last night while I was trying to prepare some remarks for this address. I was walking outside in the garden attempting to organize my thoughts when I stumbled over a stone in the ground. To my surprise as I picked myself up I saw that it had an inscription chiselled into it. With some difficulty I deciphered it; it began
“Here on this spot in the year 1500 an International Conference was held”.
It seems that a group of people had gotten together to discuss the problems posed by the numbers of art masterpieces being fabricated throughout the world; at that time it was a very flourishing industry. They thought it would be appropriate to find out if this process could be “scientificized” so they held the “International Working Conference on Masterpiece Engineering” to discuss the problem.
As I continued walking round the garden, now looking a little closer at the ground, I came across the bones of a group, still in session, attempting to write down the criteria for the design of the “Mona Lisa”. The sight reminded me strangely of our group working on the criteria for the design of an operating system.
Apparently the Conference decided that it should establish an Institute to work in more detail on production problems in the masterpiece field. So they went out into the streets of Rome and solicited a few chariot drivers, gladiators and others and put them through a five week (half-day) masterpiece creation course; then they were all put into a large room and asked to begin creating.
They soon realized that they weren’t getting much efficiency out of the Institute, so they set about equipping the masterpiece workers with some more efficient tools to help them create masterpieces. They invented power-driven chisels, automatic paint tube squeezers and so on but all this merely produced a loud outcry from the educators: “All these techniques will give the painters sloppy characteristics”, they said.
Production was still not reaching satisfactory levels so they extended the range of masterpiece support techniques with some further steps. One idea was to take a single canvas and pass it rapidly from painter to painter. While one was applying the brush the others had time to think.
The next natural step to take was, of course, to double the number of painters but before taking it they adopted a most interesting device. They decided to carry out some proper measurement of productivity. Two weeks at the Institute were spent in counting the number of brush strokes per day produced by one group of painters, and this criterion was then promptly applied in assessing the value to the enterprise of the rest. If a painter failed to turn in his twenty brush strokes per day he was clearly under-productive.
Regrettably none of these advances in knowledge seemed to have any real impact on masterpiece production and so, at length, the group decided that the basic difficulty was clearly a management problem. One of the brighter students (by the name of L. da Vinci) was instantly promoted to manager of the project, putting him in charge of procuring paints, canvases and brushes for the rest of the organisation.
Well, for all I know, the Institute may still be in existence. I leave you with one thought: in a few hundred years, somebody may unearth our tape recordings on this spot and find us equally ridiculous.
—–
Incidentally, Brian Randell writes that although he and John Buxton, in charge of editing the 1969 report, thought that “Masterpiece Engineering” provided an appropriate set of concluding remarks for the report, “we were in the event “persuaded” by the conference organizers to excise this text from the report. This was, I am sure, solely because of its sarcastic references to a “Masterpiece Engineering Institute”. I have always regretted that we gave in to the pressure and allowed our report to be censored in such a fashion.”
Catenary 
A lot of people claim software is more art than science, but there is a difference between creating the software that runs the Space Shuttle and producing a Jackson Pollock painting. Isn’t there?
In 1969 it might have seemed that creating software was going to be done by some scruffy individual in the back room, but I think time has shown this to be unworkable for modern systems.
Pingback: The Third Bit » Blog Archive » A Different Perspective
Neil,
I don’t think the argument is that software should be done by scruffy isolated individuals, but that engineering-like processes and metrics are a poor substitute for talent and craftsmanship when it comes to software development. That argument is still quite valid.
Software Engineering as you stated is no doubt a complex one to take along it is merely that 90% of job taken’s are delivered to the client with out a set of ambiguity.
The reason might be a tuff one to discuss about, but utter most is the client satisfaction which every few on the count are able to achieve and that is because they are themselves not able to figure out the necessary requirements in the initial phases.
Not to be disputatious (but that’s a big part of the fun of grad school!):
perhaps we need to distinguish between envelope-pushing domains and the well-understood ones. Presumably the engineering side is more important when you are maintaining a legacy CRM application.
Yes. It’s probably a radical design vs. normal design distinction.