Stories of Software and Systems Engineering

View My SE Web

Extreme Review: A Tale of Nakedness, Alsatians and Fagan Inspection

The Luncheon on the Grass, Edouard Manet

Two naked babies amble across a busy freeway. Trotting after them is a guy in a suit. The guy is me. Looking back on that day it’s clear that this was an omen, for within the hour I was to encounter extreme review and understand why, that for systems engineers, public nakedness is sometimes a good thing.

The Approach

Flying in from the North the scene from my starboard window was flat out stunning. The pilot dipped a wing on final approach, the blue sky rolled and the Harbour Bridge and the white sails of the Opera House rotated into view. Beautiful big brash Sydney.

Such a day. I had a right to feel good. I was carrying a million dollar proposal that, I was confident, would be accepted by a major client: IBM. My company had specialized knowledge of a small corner of the IBM software empire that guaranteed us zero competition.

It turns out that to represent the Kanji character set in IBM compiler products they needed an extra byte. Double byte enablement of IBM system software had become a cottage industry worth seven figure sums of money to small software houses. We were one.

Over the years we had developed a collaborative relationship with IBM. They were friends rather than masters. I was supremely confident, IBM was our puppy, on its back, paws in the air waiting for me to scratch its tummy.

We landed with a subtle bump and rolled to a gate. I deplaned and hurried up the air bridge into the terminal and through to the cab line.

Out of Gas

Into the cab and off, en route to IBM’s headquarters at Cumberland Forest AKA KOALA Park, a 40 minute cab ride; time to focus on the day ahead and the honeyed words that might be necessary to explain away any bumps in the estimate. I don’t talk to cab drivers on the way to a sales call. I’m usually too engaged in rehearsing the sales pitch. I seldom even know where I am or pay much attention to the scenery. So we had almost come to a stop when I noticed the absence of engine noise. I re-engaged with the moment just in time to hear the almost human sigh that an LPG powered vehicle gives out when it runs out of gas. The driver pulled over to the curb and there was silence.

Not a problem, there was plenty of time. We piled out of the cab and pushed it to the nearest service station only 200 meters away. Gassed up we were soon on our way with me back in my reverie.

Rescuing Naked Children

Two naked children walked onto the freeway in front of us. The driver made to change lanes and maneuver around them. Maybe he wasn’t a parent. I yelled, “Stop. Stop now! Pull over!” I de-cabbed, trotted over to the kids who were about to step into the fast lane and said hello. They were no older than three. I took their hands and together we slid down the freeway embankment and across a service road towards a row of houses. They could not have walked far so I approached the nearest driveway in search of a parent. There was no sign of life but for an Alsatian who trotted out from under the house with a menacing growl and a flash of sharp teeth.

I froze in place and reviewed my risk profile. Not only was I on the dog’s territory but also I probably had hold of the two youngest and most beloved members of its pack. This dog was definitely not up for a tummy scratch and we were never going to be friends. Meanwhile back in the taxi a million dollars worth of unconverted business was burning a hole in my briefcase and 30km further down the freeway was a room full of IBMers waiting expectantly. How could cruel fate seize such a day, dawned with such promise, to bury it deep in the bosom of so dark a comedy? Bill Gates had to buy a tie on the way to sell PC DOS to IBM. I have to save two naked babies and be savaged by an Alsatian? Wonderful!

A matter-of-fact voice issued from the house, “Merl the kids have got out again.” The children let go of my hands and ran inside followed by the dog, his pack recovered, his fangs retracted and my work done, apparently.

The Space Shuttle Men

Back into the cab and on to Koala Park. I was half an hour late and after another half an hour of telling the story, of the sighing cab, the naked babies and the Alsatian to a fascinated array of blue pinstriped people I presented our submission.

Space Shuttle Discovery

3 Million Lines of Code With < 300 defects

At this point in history IBM was diversifying from pure sales of big iron to software services. IBM did write software but only of the serious kind, operating systems and on-board flight software for NASA’s space shuttle. To launch their software services initiative they tasked what software development talent they had as evangelists to spread operational experience throughout the organisation. So it turned out that my two reviewers were veterans of IBM’s Federal Systems Division; they were space shuttle men.

It transpired that these men were not ordinary humans. They were fresh from a project that had delivered three million lines of code with less than three hundred errors. They were polite but earnest Americans with a disciplined presence about them, the kind that makes you want to sit up straight in your chair without being asked.

Their mission was to hold a torch to my belly, evaluate the quality of our submission and determine if my company could be trusted to modify IBM systems software products. Nice guys. The nicest grim reapers I’ve ever met.

The Extreme Review

The shuttle men had clearly read the submission thoroughly, each of them bearing a neatly documented defect list. They briefly explained the review process and mentioned a guy named Fagan[1]. It sounded ominous. I assumed they weren’t alluding to the Dickensian character from Oliver Twist. I read the lists upside down. Each defect was classified with an acronym. There were annotations indicating severity levels and blank cells on the page for verification of corrective action. At the bottom there was a cell with the title “Defect Density” and a number.

They started out by asking me about the process we used to create the cost estimate. I didn’t have a satisfactory answer because we didn’t have a process. I danced around the subject until they moved on, glancing at each other.

They started at the beginning and methodically worked through each page of the document, each reviewer raising issues from his personal defect list. I had the sense of being zoomed in on with laser-like focus. Every pixel of every font examined. The inspector’s gaze sliding over the curve of a P and dropping to examine the full stop. Is it necessary? Now he zooms out and takes in the flow of one word to another, one sentence to the next. Now he extracts, evaluates and judges my ideas in perfect rhythm with the odd asynchronous stabbing of the cognitive red pen on detecting an ambiguity, an inconsistency, an incorrect fact.

As the review progressed I could feel them breaking in. Boring through my outer shell to that inner softness that renders you vulnerability mortal; the wanting to be loved, the fear of criticism, the dread of rejection.

There was no love here but neither was there humiliation. Maybe just discipline born of a life lived with a horrible responsibility. The countdown to launch; the certain knowledge that screw-ups meant death for seven astronauts in front of a world audience with streaks of flame in the sky, with post mortems that run for years as the earth gives up its debris piece by blackened piece, not to mention the faces of the people, now members of the extended NASA family, partners and children at the graveside, and a life of eternal damnation for some simple mistake that might have been caught in a more effective review.

Their urgency was palpable. The consequences of failure had accelerated the evolution of their review process. The discipline was in their nature and not to be forsworn for less critical application domains. It didn’t matter that this was a harmless double byte enablement project, this wasn’t going to be a ticklish torch to my belly, nor was I going to be scratching anyone’s tummy. This was main engine thrust.

They tore our submission apart with surgical precision, identifying elements of the quote that had been double dipped (an honest mistake on our part). I had a flashback to an epic fist fight with a class mate at boarding school. He was a trained boxer. It went on for 2 hours until he finally knocked me senseless. After a while I actually began to admire his work. His punches would appear from nowhere and slam into my face. Luckily the IBMers were more focused on my work. Their blows were precisely targeted, accurate and completely righteous. All the while they remained in good humor and, when it was over, delivered their exit decision in polite civility. “Due to the high defect density in your submission, you need to perform corrective action and resubmit for full review.” We shook hands and bade farewell.


Back into a cab and out onto the freeway, we sailed past the baby house. They’d be having their dinner by now and then to bed to dream of trucks in the fast lane and the anguished face of the stranger on the freeway. Three faces had filled my day. The innocence of children, the primal pre-feeding gape of the Alsatian and the look of professionalism in peer review. In two hours I’d been dragged onto some higher, more evolved plane of systems engineering that I never knew existed. Now my company would have to come with me if we were to do business with IBM. I remember feeling no pain and wondering why.

Creativity and Pain

Reviews can be excruciating for the unevolved. In fact the entire writing process is redolent with pain. You struggle with ideas and search in vain for the words to express them. And in the back of your brain there plays a negative litany that will not go away. Elizabeth Gilbert summarised it beautifully in a TED talk:

Aren’t you afraid that you’re going to work your whole life at this craft and nothing’s ever going to come of it and you’re going to die on a scrap heap of broken dreams with your mouth filled with bitter ash of failure?

Finally words do appear. You push them around with a mouse endlessly cutting and pasting until thoughts congeal into ink and you begin to fall in love with your words on the page. They take on intrinsic beauty self evident to you and ergo to the remainder of humanity. Or so you think.

Then heaven descends to earth, dreams are crushed by reality, beauty is no longer what it has been, even the gods become ordinary. You lay your work at the feet of your peers – and they savage it.

Going Naked

To submit your work to criticism is to reveal yourself. To go naked in public. Some authors liken it to inviting the world into bed with you.

For sure in polite society public nakedness is an unnatural act. Edouard Manet scandalised Paris with his painting Le Déjeuner Sur L’Herbe (The Luncheon on the Grass) depicting a naked woman picnicking with two men (see the banner above). The Paris Salon jury of 1863 called it an affront to the propriety of the time and rejected it out of hand.

In stark contrast IBM’s twentieth century salon had demanded my nakedness and inspected every zit. It grabbed me by the scruff of the neck, held my face to a mirror and made me look at myself as those, more evolved than I, saw me. I was reminded that systems engineering is not polite society. Sure, going naked is unnatural but so is every other aspect of a disciplined life. It’s learned, evolved and can’t be achieved without pain.

Dealing With Fear of Criticism

Afghanistan, June 11, 2010. An Australian SAS troop runs into an Taliban ambush. Ignoring withering fire from three elevated machine-gun emplacements Corporal Ben Roberts-Smith single-handedly silences two machine-guns and is awarded the Victoria Cross, Australia’s highest military honour.

When asked how he deals with fear he says, “Recognise it and understand it clinically. Generally, fear manifests itself as adrenaline so if you can recognise it you can control it. In my opinion, being able to control fear is what determines bravery.”

The review room is not a battlefield. A high defect density in your work is probably not going to get you killed. But just like Ben, getting over the fear of criticism requires you to recognise your humanity and learn to deal with it. Accept that there is an element of vanity in everything you publish. You have an ego which blinds you to defects in your own work, you make unconscious assumptions that are not valid for all situations and you hold beliefs that become transparently illogical when voiced out loud to others.

Professionals recognize and deal with these natural pathologies by embracing peer review. Even Ernest Hemingway, an icon of American literature, invited friends over to help him remove superfluous words from his manuscripts. Always the honest professional he said that, “the first draft of anything is shit.”

So there you have it, if you aspire to professionalism, be honest, accept criticism and harden up – unless of course your being reviewed by bozos.

Recognising Bozo Review

I like to put my inquisitors under pressure. Edgy reviewers are much more productive. I create positive tension by telling them the shuttle men story with the punch line, “For you, they’re a hard act to follow, I hope you’re up to it.”

There is such a thing as bad criticism. Steve Jobs was a world champion at it. For example, he asked his marketing team to come up with names for a new Apple Computer. They responded with five options one of which was “iMac”. His response was: “they suck”. He began to warm to iMac but continued, “I don’t hate it this week, but I still don’t like it.” Whenever his creatives asked him what he wanted, a common response was, “you’ve got to show me some stuff, and I’ll know it when I see it.” Worse he had a nasty habit of humiliating people in public, not only criticising their work but also trashing their personalities, flinging indictments such as “I’m trying to save the company here and you’re screwing it up” and using choice adjectives such as “stupid”. At times it got so bad that wiser heads would take him aside, explain how hard everyone was working and suggest: “When you humiliate them, it’s more debilitating than stimulating.”

Jobs was a creative genius working in a supernatural world where futures were predicted and then delivered. He was so often right that his people endured his tantrums putting it down to creative passion. Most of us don’t get cut that kind of slack. Most of us live in a world where defects are banal and more easily defined if we choose to be diligent. At the micro level it’s an ambiguity, an incorrect fact an inconsistency or maybe just a missing full stop. At the macro level it’s a non compliance with a pre-existing specification or it might be a violation of an agreed upon best practice.

In our normal world there is no excuse for bozo review. Bozo reviewers turn up at meetings without thoroughly reading the target document. Bozos make “this is crap” comments that denigrate the author, they gesture fecklessly at paragraphs with vague pronouncements of “I hate it”, and worse, they scrawl lone red coloured question marks in the margin of documents. What could this mean? Other classics from my recent past include, “rubbish”, “it’s tacky” and “you’re trying to show off”.

Suffice to say that any utterance from a reviewer that does not directly, and in the most efficient manner possible, contribute to the improvement of the work under review is bad criticism.

Reviewers! If you can’t be explicit it won’t get fixed, and as for character assassination; changing a person’s personality can be a lifetime project, most people over the age of five are pretty much hard wired – better to concentrate on what can be improved in the space of an hour and that is: the quality of the work.

The Reviewer as Teacher

I weep for organisations that don’t review regularly. The insightful review is the most effective teaching tool we have. For a start, reviewees have their heart, soul and skin in the game. You’ve got their full attention. You’re dealing with their baby, the piece of themselves they’ve nurtured into life for weeks and sometimes months. Precise, improvement oriented problem statements delivered in a non-threatening environment find an impedance match to the creative brain. Advice passes through with no component reflected back. Reflection on what went wrong followed by corrective action is the most effective learning process known to man.

Well at End

In the week following the review we fixed the defects and resubmitted our proposal. It was accepted and my company went on to develop a multimillion dollar line of business with IBM.

My day with the shuttle men happened 25 years ago yet I remember it as though it were yesterday. I remember it for the sighing broken down cab and the naked babies on the freeway but mostly for the relentless professionalism of those earnest Americans.

In a single afternoon they opened my eyes to a new way of operating. I was naked in public but felt no shame because they accepted me as I was and focused on my work with a bent to improvement. Talk about an accelerated education! Many things:

that to review is to judge and be judged, not only by what you give to your peers, but by what you do not take away; dignity

and to accept critique is to stay young and open to the possibilities

and beware the vanity of vanities lest they morph into conceit and perhaps then to arrogance leaving you all the while learning less and less to an end point of nothing

and keep your cheek to the Earth, aware of your flawed humanity but comfortable in your own skin – naked or no, for as Baudelaire said:

The body’s beauty is a sublime gift
that extracts a pardon for every infamy


Note 1
Michael Fagan invented a formal process for finding defects in development documents such as programming code, specifications and designs. His seminal paper on this subject was published in a 1976 IBM Systems Journal. More than thirty years later his inspection process is still recognised as one of the most effective software quality assurance techniques. Fagan inspections can be applied to software development at all stages of the life cycle.

Fagan, M. (1976) Design and code inspections to reduce errors in program development, IBM Systems Journal, Vol. 15, No. 3, pp. 182-211, [Online], Available: [19 May 2012]



  1. […] connected Fagan inspections in Extreme Review […]


    Hi there, just wanted to tell you, I loved this article. It was helpful. Keep on posting!…

Leave a Reply

You must be logged in to post a comment.