I’m taking a course in business communication about software development this week from the famous Tom Gilb. He is the co-author with Dorothy Graham of the book Software Inspection, which is an expansion of the relatively famous Fagin inspection method pioneered at IBM in the 1950s. This is the second course I’ve taken from him; the first one was the second day I was in the United Kingdom, back in January of 1994. It was a course to qualify me as a manager of the inspection process. Unfortunately, the company didn’t use inspections for very long (they are time-consuming and expensive), so I haven’t done an inspection for a while.
So today was the first day of this week-long course. One thing that has struck me from the first time I met Tom: his courses and books may have ostensible titles like “Software Inspection” or “Principles of Software Engineering Management”, but they are actually all variations on the same subject: “Tom Gilb”. He has been in the software business for 52 years, and has built up such a history that everything he does is couched in war stories which star himself.
There is no doubt that Tom is gifted, highly intelligent, insightful about the processes around software engineering, and articulate. However, everything he talks and writes about revolves around himself and his exploits.
I have come to the conclusion that this is kind of tired and intrudes into the process of learning some of the doubtless valuable lessons and insights he has to offer.
Another interesting thing that I’ve noticed is that many of the delegates, who only know him from his reputation and his books, are so in awe of him that they treat him with the kind of reverence normally reserved for Popes or cardinals, or at least archbishops. They seem to believe that every morsel of information that emerges from his mouth is sacred. While I don’t share this reverence (I know of at least one occasion where he let down a mutual friend in order to court another possible business contact) it does intrude on the learning process.
The really good thing about this course is that it is free to people who are not currently employed. There was thus an enormous takeup, of course, and there are 30 people (plus Tom and his wife, who is kind of a power behind the throne, making sure that everything runs smoothly) in the room. There are two to a table, with 15 tables in a room designed for 10. There are not enough power points for all the delegates—thus, those of us who arrived closer to 9 am had no power point and my netbook ran out of juice by mid-afternoon.
The course goes until Friday. At the end I’ll recap what I believe I learned from it.
I am very curious to know what he says about Inspection and other forms of Peer Review and about the use of tools to help out. Please let me know.
I can tell you right now what he thinks about inspection.
At one time (when he co-wrote the first edition of Software Inspection) he felt that the entire document should be chunked up and inspected in the first instance. He has now changed his mind, I think partially from the undeniable fact that no matter how much proselytising he does companies cannot get over the hump of the expense and difficulty of doing inspection correctly. Those that start often stop doing it within a short time (like the company I worked for) and many, after hearing about it, do not go further with it.
He now advocates taking pieces of the document at random and inspecting those smaller pieces first. If the document is judged unusable after inspecting those smaller chunks, the document is not worth further inspection and is sent back to the author for reworking.
I do not believe (although he has not said it outright) that Gilb is in favour of tools for inspection or peer review. In general, his war stories depend upon human effort at inspection rather than using tools. ISTR from the first course I took that he was not against using tools to help in the effort (such as spreadsheets to coorelate error recording) but he has actually stopped advocating recording errors in formal inspection meetings, at least on first reading.
He asks people to inspect their chunks and report the number of major issues they find. Before the inspection the acceptable number of found major issues per page is determined (1, 0.5, whatever) and he then polls the inspectors: “How many majors did you find?” Let’s say he comes up with “25, 35, 24, 42”. He then doubles the largest number and would come up with “84 major issues” in the chunk. This would be the gross number of different issues that all four inspectors found (remember, this is without listing them out). Then, treble that number, and you come up with “around 250 +/- 20 major issues” per page—his contention, borne out by his experience, is that only about 1/3 of major issues are discovered at any one inspection.
He then sends the author away with everyone’s lists of major issues (without ever actually discussing them) and when the issues are corrected, re-inspects. More major issues are found, not only the 10% or so of reworks that are themselves erroneous, but other major issues that were obscured by issues in the first round of inspection. This continues until the number of majors is at or below the acceptable level.
He does not mention tools for this task, nor is he concerned anymore with minor issues. Spell-checkers, syntax-checkers and the like are assumed, I think. Any document that has spelling mistakes (your scribe would not pass this test…) is assumed not to be ready to inspect.
We are looking at requirements at the present time, and how most organisation fail miserably at producing requirements that are clear, free of methods, and unambiguous. The material is a series of war stories about how organisations called Tom in because their projects were failing and he showed then in a trice how crap their requirements were. Either the company adopted his methods (in which case all was saved) or it rejected it and him and failed.
Apparently he is taking the credit for trying to save Lehmann Brothers from itself, as they called him in a year before the financial meltdown, he arrived and did his magic show, and they were not interested in taking up his ideas on inspection and requirements. Thus, they folded a year later. I don’t know whether he’s saying that they would have survived had they paid attention to him, but he is certainly implying that their internal processes were shoddy and that he advised on how to improve, but was shown the door.
This is all after only the first day…I look forward to hearing about the rest of his exploits in trying to save businesses from themselves in the next four days.