At this point in history no one can prove that, pre-deployment, a given body of software will be reliable and, more importantly, safe in all operational situations. The next time you board an aircraft no one can guarantee 100% that you’ll make it to your destination. Probability is always involved. In 2018-19 three hundred and forty-six passengers on two Boeing 737 Max flights didn’t.
You might be wondering why aircraft and automobile manufacturers are allowed to use software to perform life critical functions in their products. For example, Airbus fly-by-wire systems and the currently much hyped self-driving cars.

The answer is that certification bodies responsible for public safety in domains such as aviation, rail and road transportation require the developers of safety critical software intensive systems to follow heavily codified systems development processes. They need to comply and be able to prove they’ve complied with designated development standards before their software can be deployed for public use. The logic is, ‘If it’s developed with rigour it’s acceptably safe’.
But here’s the rub. Organizations that develop this class of software need to be highly disciplined to meet the constraints imposed by these standards. Garage startups need not apply. In systems engineering the level of discipline is codified in measurable ‘maturity levels’. In practice the getting of ‘maturity’ (called process improvement) is a long, hard and messy row to hoe. There is fear, uncertainty and doubt because success requires all players to not only learn the process but also to believe that the new way of working will improve safety. All this in an environment where the proof of effectiveness can be years down the track and take the nebulous form of ‘nothing bad happened’.
Belief is important because it motivates all our actions, especially in high stress situations like deadline death marches where the pressure to cut corners is overwhelming. Learning informs on the right way forward. Belief drives you to perform.
No one taught me how to modify belief systems in engineering school so it was left to cruel experience to give me the test first and the tutorial later. I was once on the management team of a small software house with big ambitions. This is the true story of the painful process improvement adventure that led us to believe in ‘Better’.

Motivation for Better

We all so desperately want to be good that we spend much of our reverie in anguish over not being good enough. Then spend our waking lives in a struggle to be better. But Better is expensive with a price some of us are unwilling to pay. In the parade of humanity the selection of the good from the average is made by the strength of resolve to keep on, through the sweat and the tears and the doubts raised by others who have given up at good-enough. Where-from this resolve, and why is it stronger in some than in others? Can it be learned by anyone or is it informed by some attendant spirit that manifests only to a select few?

I once served on a management team that resolved to get better at delivering fixed price software intensive systems. The initiative was conceived in pain and we suffered a lot in the doing. I’d like to say it was a solid business decision informed by facts, based on evidence, but, as is often the case with big decisions, facts are scarce and evidence goes missing. Frankly we started out and kept going through an act of faith. Where did our inspiration come from? On the face of it we were driven by a profit motive; hang about though, years on, I have discovered our deeper, more powerful and unknowing purpose at the heart of an Iroquois Indian legend.

In a Cane Field

It began with Glenn Holliman in a Fijian sugar cane field. It was crushing season and Glenn had been sent to install a weighbridge automation system. The cane was weighed at the entrance to the sugar mill and on those numbers the farmers were paid. Without weight the cane could not be processed; the mill could not run. As Glenn bent to his task there was movement in the fields as machines commenced the harvest, loading the cane into rail trucks for the short journey to the mill.

Progress with weighbridge commissioning was glacial. Glenn’s software had bugs. In the evening he would call our company’s Brisbane office to discuss fixes and in the morning he would make changes, retest and spend the remainder of the day discovering whole new ways for the system to fail.

The Sugar Train

The mill manager was an Indian with the demeanour of a regimental sergeant major and a turn of phrase dredged up and refined from the gutter talk of a hundred Indian dialects over two millennia. As the cane trucks drew closer, the emotional weight of his curses bore down upon this engineer. Not withstanding, the debugging continued.

In the harvest season sugar cane is burned to kill micro organisms, to remove trash leaves and to keep the soil rich. Late at night, surrounded by cane fires, assailed by a conga line of fatal error messages, with ash and insults raining down, others may have despaired, but not Glenn. A student of language he leaned in, regarding the Indian’s depth and range of expression with awe. One morning, with the cane trucks in sight, his attention was rewarded with the most sublime explicative he had ever heard: “Salah – I have known your sister.” Glenn drew out a pencil and wrote it down.

…………………….

In another time on the banks of the Hudson River in the region now known as upstate New York, there lived the Iroquois Indian Nation. Each year the tribes moved to a different place for the hunting season. Legend has it that one year, as normal,  a council was called and a location chosen. Unfortunately the elders did not know that they had settled on territory inhabited by wolves. Accordingly the tribes suffered repeated attacks and many were killed. A council was called to make a choice: either kill the wolves or relocate the camp.

…………………….

In Fiji, Glenn was proving that man is a creature who can get used to anything. Seared by fire and verbal abuse, but unphased, he applied the survivor’s four tools of mind: humility, wonder, imagination and cold logical determination. Ever confident, he clawed his way out of a pit of crap code and commissioned the weigh bridge. He tarried briefly to witness a relieved manager fire up his sugar mill. As far as the Indian was concerned there were no hard feelings. The rule of Greek tragedian Aeschylus was applied: “Victory in whose august glow all felonies are effaced … ” There were assurances that invoices would be paid.

The Inflection Point

Back in the Brisbane office Glenn came through the door back lit with the aura of victory. Coriolanus fresh from the battlefield, slightly elevated and ready to address the mob, his right hand bearing the gore-covered armour of his enemy; in possession of practical wisdom not to be challenged by the feeble spin of desk-driving, rear echelon types such as us (the management team). I remember feeling small and somewhat jealous in his company. After all, I used to be him. The guy who wrote the logic and loved it. The guy plugging ones and zeroes into a control computer while, on the other side of the blast wall, reaction kinetics did my bidding. At times like this I regretted trading in that life for a management job with a high level decision making role that was seldom recognised as heroic.

Coming off a successful project is like money in the bank to an engineer. It has a short shelf life though, one subsequent failure and you lose the lot. It seems that we’re only as good as our last project. But for now Glenn was flush and he spent his capital well, facing us down and coming straight to the point. “What were you guys trying to f***ing do to me with that garbage code? You could have got me lynched for delaying the crushing season. We can’t keep operating like this. Something’s got to change around here.”

Andrew Grove

Andy Grove speaks of inflection points, when it becomes obvious that a business has to take a new direction. With Intel Corp it was the loss of the memory chip business to more efficient Japanese silicon foundries. These events triggered Intel’s increased focus on microprocessors. In his book, Only the Paranoid Survive³ Grove relates how difficult it was to identify that an inflection point had, in fact, arrived; management typically has a huge investment in the status quo. Grove finally hit on a workable test. In a meeting with his boss he asked, “What if they fired us both tomorrow? What would our successors do?” The answer was obvious: “Get out of memories and into processors – with both feet!”

For us it was easier I think. Here we were, faced with this straight talking country kid, fresh from the fires of a Fiji cane field, asking a fair question: “What are you going to do about this mess?”

It was time to study the book of the earth and find a different track.

Cleaning Up Our Act

The source of our problems was not hard to find. We suffered from all the maladies that punish undisciplined software houses even to this day:

• Absence of a formal software development process with management visibility and formal progress review
• Lack of complete and correct requirements specifications
• Lack of documented and formally reviewed architecture specifications and detailed designs
• No coding standards or code reviews
• Add hock testing.

Accordingly we set about cleaning up our act. It was painful because it meant we had to take good people out of billable work to write standards and procedures.  Worse, when it came to rolling out new processes in live projects we found it made us more expensive. It turned out that writing complete, correct and unambiguous requirements specifications costs money, documenting and reviewing designs consumes resources and thorough testing is time consuming. Up until that time our average project was valued at $40,000. Enter big M methodology and we found getting out of bed for less than $100,000 a chore. Better wasn’t quicker or cheaper. Worse still, we were cut no slack by the owner of the company who refused to invest in our process improvement initiative requiring a consistent 25% return on costs. It looked like Tom DeMarco was right. “Quality is free. But only if you are willing to pay dearly for it.”

And pay we did, on a daily basis, in fear that the increased paper flow would fill our days with busy work for no real gain, that standards for design documentation would crush the souls of our most productive creatives encouraging them to quit and that endless reviews would slow progress and price us out of the market.

We had embarked on an act of faith – “to him that overcometh will I give to eat of the tree of life” – but it was costing us dearly and we knew it would not have an immediate impact on our profitability.  It was a medium term initiative for a small company with a short term horizon.  Financial performance was evaluated every six months. Any hint of a failure to make profit targets turned the owner into a wolf in wolf’s clothing. There were no hard feelings, a wolf must do what a wolf must do, the boss had a “time-to-zero calculation”; at zero he’d lost his house and the ability too feed his children.  Ergo a management team that did not deliver income had no job.

The Day the Model Broke

In our hearts and minds we all carry a mental model of the real world. We need it to exert some control over our lives, to predict responses to our actions, to plan for the future and to find the toilet in the dark. We of the management team had a shared model. Collectively we held dear that the marketplace would embrace us as a respected vendor of quality software, even if we were a little (well maybe a lot) more expensive. This made it all the more devastating on the day the model broke, reality refused to conform to our expectations and we were punished by the indifferent forces of nature.

We bid on a weighbridge automation system for a central Queensland sugar mill. The company was a long standing client so it was expected that the offer and acceptance would be routine. Our price was $250,000. We lost. The work was awarded to a back yard operation in Bundaberg at an asking price of $40,000. Our sales territory was filling up with people in garages. Customers were intrigued with the romance of it. Anyone in a dimly lit room with jeans, a T-shirt and a can of Jolt Cola had to be a genius. And they were so cheap. I had never known there were so many hackers on the earth.

The Dark Night of Choice

My boss was a chemical engineer with a Ph.D. which qualified him for the nickname: Dr Bob. He was a man of agile mind and practical intelligence. We shared the business development role. I often wondered how he found the hours in the day to manage the team and work with clients the way he did.

Bob didn’t have to call an emergency management team meeting when we heard the news, the management team spontaneously materialized in his office. We clearly had to make some choices. Our inflection point had arrived. We’d embarked on the path to Better but did we have the guts to keep going?

…………………….

Iroquois Longhouse

The tribal council of the Iroquois met in their long house by the Hudson. The Iroquois were also known as the Haudenosaunee or the “People of the Longhouse”. These were not trivial structures, nor was the decision to move a nation on the strength of a pack of nasty animals. A more compelling reason would have to be in play, something anchored in the nation’s fundamental belief systems.

The options were canvassed back and forth: kill the wolves; move the nation. Details of the arguments for and against will never be known but the final choice speaks well of the Iroquois. They moved on.

The legend carries this decision’s rationale as a lesson in ethics to descendant generations: that killing the wolves would be against nature; that destroying other sentient beings over which they had power, for no other reason than territory, when there was enough for all, was immoral and that in committing this act they would not be the human beings that they wanted to be. In short, IT WOULD DIMINISH THEM.

…………………….

We moved the impromptu meeting to a conference room that overlooked the Brisbane River. As the sun went down we batted the options back and forth. We had plenty of talented people. Couldn’t we just assign tiger teams of one or two engineers to small projects ($50,000 and below) and exempt them from the expensive software process overheads? The directive would be precise: “Go on lads. Hack! Just don’t screw it up.” We knew this was doable because we’d been doing it for years. Take Glenn. He could hack code in the middle of nowhere with flames lapping at his space bar. He delivered. We got paid. What could go wrong?

The meeting wore on and a slick mist rose from the river seven floors down. Standing still was clearly not an option, hanging around waiting for fate to take over was a bad idea; in a dark night, four men stood with their feet in a fire figuring on which way to run.

Other mental models emerged. It turns out there can be more than one reality. Someone pointed out that we were wasting Glenn’s talents on a $50,000 project when he could, armed with our shiny new disciplines, be running a million dollar project and earning a $250,000 profit. “And oh by the way do you think he enjoyed hacking code in a cane field with attendant flames and rabid mill managers suggesting they’d had sex with his sister? In asking him to do this are we not diminishing him, asking him to be someone he does not want to be? In asking any one of our people to bug fix failing software on-site under the gaze of our customers, are we not diminishing ourselves as an organization?”

In the end, around midnight, opinions aligned and we resolved to press on with process improvement and not participate in the race to the bottom that beckoned in the small project marketplace. I can’t say exactly what drove the decision. Flashes of insight are never available in the moment. They distil over time and come to you years hence in short sentences dense with meaning; those brief moments when you have faith that everything you’ve been is more than nothing, that you’ve fulfilled some purpose; done something of value. Back in the moment though, it’s never clear, the only guidance being reflex action driven by something deep and primal – that we later disguise as “strategic thinking”.

I had the sense of someone watching us from a darkened corner.

…………………….

Having made the decision to move camp, the Iroquois tribal council also determined that, to avoid repetition of this mistake, they would appoint someone to represent the wolves in all future decision making. Their opinion would be sought with the question, “Who speaks for the wolf?”

…………………….

Who Speaks for the Wolf?

Ever since I heard of Nietzsche’s aphorism that truth is a mobile army of metaphors, I’ve been on the lookout. The metaphor of wolf-as-spokesman caught my attention.  What did it mean? Dropped naked onto the earth an Iroquois Indian would be living comfortably in less than a week. In the forest he saw every living plant and knew the seasons when he could eat or use it for medicine; he read the tracks of every creature that passed through and sensed every shift in the wind. Had he also tamed the abstract world of truth? The Greek philosopher Heraclitus said: “Even a soul submerged in sleep is hard at work and helps make something of the world.” So I handed the riddle over to my subconscious and waited.

A week later I was rewarded with insights on the forces that savaged us on the weighbridge bid. When you move into any new territory problems and opportunities manifest as characters: heroes and villains, deeds: evil and good and situations: comfort by the fire and death in the snow. Survival instincts unleash primal forces. Nature heeds only the orientation of the earth to the sun, it has no mercy and no aspiration but self interest. Projecting nature onto the experience of a software house, it becomes “the real world”, that random, sometimes violent and careless territory into which we deploy our complex systems. The world that doesn’t behave rationally, that refuses to conform to our mental models and, as a result, often punishes us for our naivety when we attempt to order it with the pure logic of software.

Nature is a foul mouthed mill manager who’s one aim in life is to crush sugar cane, caring little for the intricacies of real time control systems. Nature is the mill owner with a $40,000 budget for a weighbridge automation system and no desire to invest in a $250,000 product regardless of how elegant it’s design and how steeped in best practice it’s development. Nature is the business owner who wants a more compelling case than “trust us, we want to be better,” to justify spending his treasure on process improvement. Nature is a careless, selfish and hungry wolf. When planning any new initiative on his territory it therefore profits us to invite him to the table and hear him out.

Back in the day events played out to validate this idea. One wonders: is life legend or legend life?

The Walker Street Massacre

At this time we had engaged with some large organizations: IBM and Telstra. The Australian government had instituted and offsets program that required multinationals doing business in Australia to allocate work to Australian companies. As business development manager I began to wear a track south to new territory: Sydney and Melbourne.

Dr Bob and I made the Better project the centrepiece of our sales presentations and pushed hard for feedback. Were we on the right track? Was such a thing of value? And they welcomed us, bless them, these benevolent creatures in their pinstriped suits. At the table with the inhabitants of our new territory we discovered a more evolved species, millennia ahead of your average mill owner. They expected “process” as a sign of maturity in a fixed price software house and were willing to pay for the feeling confidence it engendered in a predictable project outcome. Some of them were more extreme than us urging us on to greater heights (refer Extreme Review).

I can’t say it all went smoothly. There were smoke and mirrors with engineers behind curtains, for even as we extolled the virtues of our development process we were busily developing same in the hope that, if we ever did sign a large project, we would be positioned to practice what we preached. In many respects we were babes in strange woods where life could be dangerous. Often (sometimes unknowingly) we presented our Better story to hardened players, men who had forgotten more about software development than we ever knew: systems engineers from IBM’s Federal Systems Division (the guys who put software in space shuttles) and development lab managers responsible for IBM’s systems products (compilers, assemblers and operating systems). One day the inevitable happened, we were caught out and savaged.

Dr Bob and I were on a tour of IBM’s Walker Street, Sydney headquarters when, on a chance meeting in a hallway, our guide introduced us to IBM’s Tokyo language lab manager. There he was, one of these mythological creatures come to earth briefly to dispense wisdom, set the fate of humanity and possibly mate with a mortal woman (read software house). And what riches would flow from this union: millions of dollars worth of projects. If only we could impress. I remember him scanning our beaming faces and uttering one sentence: “What’s your a-purs per ka-lec?” And there you have it, nailed to the wall by the question with no honest answer but “I dunno”. In fact I didn’t understand the question let alone have a credible response. There was silence. Stony silence. For me it was all over, I imagined myself selling pencils on the street or maybe I could, Conrad-like, find a river, follow it to its source and seek my fortune in a B movie replay of the Heart of Darkness. Then into the breach stepped Dr Bob, erstwhile graduate of the Anglican Church Grammar School for Boys and darling of the debating team.

I’d seen Bob in action before in situations just like this and was in total awe of his abilities. Temporarily flummoxed for an immediate response he’d lay down a prophylactic mist of sentences, keeping all anxieties tranquilised and all boredom amused, all the while in the background composing something valuable to say. I recognised the face. That expression he put on when his brain went into cognitive overdrive, assessing the sales situation and selecting the perfect answer. I waited with growing concern as the verbal idling spun on for longer than normal until, in horror, I realised that he didn’t have a clue either. Worse, the tranquiliser wasn’t working. The lab manager’s penetrating gaze hardened then glazed over and, having other fish to fry, moved on down the corridor shaking his head, a practical man with no patience for foolish talk.

Our non-answer to the seminal question may have wounded our business interests but the damage turned out to be nonlethal. No matter, the significance of this incident was not lost on us. It became known as the Walker Street Massacre and passed into legend. Nor did we leave it at that. No. We drew out our pencils, noted it down: “a-purs per ka-lec” and resolved to discover its meaning, sharpish like.

In the final analysis our sales campaign was successful. Soon after our Walker Street visit we signed projects. Talk of Better had made us more attractive to larger, more technically mature organizations with expensive problems and substantial budgets to match. In my stream of consciousness that often flowed in the cab to the airport, I imagined the footpaths of Sydney and Melbourne to be paved in gold!

Better is Good

In general, Better turned out to be a good idea.  In the years that followed our talk transformed into action with a strong focus on development discipline that made our projects more predictable. The precision of our estimates improved out of sight. Detailed requirements improved our relationships with clients and made the design process more efficient.  More considered designs, documented and peer reviewed, cut down coding rework. Code reviews caught problems early increasing our defect removal efficiency. Thorough factory testing eliminated fire fighting in commissioning.

There were also welcome side effects: consistent process enabled us to easily move people between projects it also reduced the time it took to induct a new employee, graduate engineers became productive in less than a month. A formally defined methodology allowed us to make incremental improvements and track process performance across all projects with simple metrics.

Research triggered by The Walker Street Massacre revealed: a-purs per ka-lec meant APAR/KLOC.

Where:

APAR – Authorized Program Analysis Report. A formal report to IBM development, of a problem caused by a suspected defect in a current unaltered release of an IBM program.

KLOC – Thousand lines of code.

Mr A-Pur wanted to know the average defect density in our delivered software. He was attempting to cut through the fog of sales speak and look into the very soul of this software house. If we could understand the question it meant that we at least had software quality control aspirations. If we could quote any number at all, it meant we had a software quality control system of sorts. If the number was in the range 1 – 10 we were about a mature as Microsoft. Anywhere between .1 and zero classed us as peers of NASA’s space shuttle avionics team.

Happily our fears of commercial oblivion at the hands of big M methodology were exaggerated. Discipline did not constrain our people, it freed them. It made them capable of taking on bigger technical challenges; more interesting projects. And in the doing they grew and developed into the human beings they wanted to be. Technical nobility was earned from consistent success as opposed to heroics in burning cane fields.

As time passed it became clear that our cane field based mental model was but a small component of a much larger reality. We began to sign larger projects and put on a growth spurt. A million dollar project became common place, none of which would have been possible without the choices made on the dark night. We were soon out of the cane fields and ranging further a field. If you like, our tribe respectfully moved on leaving the primal, yet noble, backyard wolves to their territory.

The Sublime Moment of Validation

There is no question that, in our case, the Better strategy was a success, however it is fair to say that it could have been a fluke; a happy coincidence of action and circumstance. Ergo, some years later, I was fascinated to read a story in the Harvard Business Review¹ that seemed to validate our strategy as a fundamental theorem of goodness as opposed to a lucky one-off.

…………………….

USA Circa 2013

Michael Raynor and Mumtaz Ahmed questioned the potency of published how-to-succeed in-business advice. Too many published case studies of exceptional performance are the result of lucky coincidences and random shifts in market conditions. They posed the question: “Is there some X factor in the way a company operates that can give rise to success sustained for decades?”

In search of a defendable answer they studied data from 25,000 companies that have traded on U.S. stock exchanges in the period 1966 to 2010. They measured performance using return on assets, a metric that reflects fundamental value and filters out the fear and greed driven fluctuations of the stock market. Their conclusions, published in the Harvard Business Review, were:

When truly great companies make choices they are guided by three elemental rules:

1. Better before cheaper  – in other words, compete on differentiators other than price.
2. Revenue before cost  – that is, prioritize increasing revenue over reducing costs.
3. There are no other rules- so change anything you must to follow Rules 1 and 2.

But that was not the end of it. Elemental rules are fun but far too abstract for the average consumer of business books; they want something more vivid and concrete, like behaviours expressed as: Step 1, Step 2 and Step 3.  So Michael and Mumtaz soldiered on, attempting to nucleate, from the philosophical mist, some kernels of practical wisdom. Flummoxed for some time they finally concluded that it was not what companies DID that was important but HOW THEY THOUGHT; most importantly, how they made choices. Ecstatic they drew out their pencils and wrote this down:

“Every company faces a choice: It can compete mainly by offering superior non price benefits such as a great brand, an exciting style, or excellent functionality, durability, or convenience; or it can meet some minimal acceptable standard along these dimensions and try to attract customers with lower prices. Miracle workers [companies who succeed for decades] overwhelmingly adopt the former position. Average Joes typically compete on price.”

And then towards the end of the article they reduced their findings to practice:

“The next time you find yourself having to allocate scarce resources among competing priorities, think about which initiatives will contribute most to enhancing the nonprice elements of your position and which will allow you to charge higher prices or to sell in greater volume. Then give those the nod.”

…………………….

So there you have it, validation most sublime: elemental thought along the lines of goodness, practiced by a management team gets results in all kinds of business environments. It is particularly relevant to software development where most of the effort is in knowledge work, artifacts assembled by the mind, invisible in production and expensive to fix if done wrong. High quality software can therefore only be assembled by minds aligned in Better thought processes.

And now for my deeper purpose: to explore ways of encouraging people to think Better thoughts, to close the gap between what we know is right and what we actually do at a keyboard. For example, how can a truism be transformed into a belief system held by all parties to a software project and how can a belief be translated to action?

Giving in to Better

I discovered the Iroquois legend in Mark Rowlands’ book The Philosopher and the Wolf². The simple phrase “it would diminish them” leapt off the page and transported me back 25 years to the dark night. With uncanny clarity I looked into the faces of my friends on the management team, saw the mist on the river, heard the conversations and remembered the choice we made.

Would a knowledge of American Indian lore have helped us on that day? Maybe, but a more fascinating thought is this: even though we knew nothing of them, our collective reasoning moved along the same lines as Michael,  Mumtaz and the Iroquois as if aligned by some timeless cognitive force field. I wondered: is it our instinctive human state to want Better? In doing the right thing are we not going beyond our nature, but giving in to it? I may be a romantic but I like to think that, had we known of the Iroquois, we would have made our choice with more faith and less fear. For just as the Brisbane and the Hudson flow into the same ocean system so does the wisdom of the ages come together in one place: in the myths and legends of all civilizations, invariant in time, true until eternity and most worthy of our attention.

Reducing Myth and Legend to Practice

The dark night happened decades ago. I am older now and, I hope, a little wiser. I have come to believe that you can leverage the wisdom in classical mythology to enhance your technical career, simply because the hardest choices you will make are informed by morality not technology. In my case, executing a process improvement program was a mechanical thing; well understood; much like moving a longhouse 100 km down a river. There is no shortage of guidance in the literature, effective software development processes are documented in many published frameworks.

My favourite is Watts Humphrey’s Personal Software Process (PSP) and its extension to the Team Software Process (TSP)⁵. Documentation aside, the real toil is in choosing the Better direction and staying the course. For example the PSP/TSP with its emphasis on practice, practice, practice – is hard work. It requires you to track personal and team productivity and have a ready answer to the “a-purs per ka-lec ” question. And it doesn’t stop there, you need to reflect on what went wrong, documenting and executing an improvement plan. It’s possible Watts may have studied the Roman philosopher Rufus⁴ who told his students: “… a person who wants to be good should not only thoroughly learn the teachings, but also practice doing them …”. Overall I have no doubt that the reason for PSP/TSP’s success lies in developing highly trained individuals whose thoughts are aligned in the Better force field from an early age. In short, helping people become the human beings they want to be and, in moments of doubt, buoying them up with the sense that this is a right thing to do.

The Life Function of Myth

Computer scientists advance the science. Software engineers apply the science. Computer scientists evolve pure theory while software engineers throw it to the wolves. We mash it, pragmatize it, make it usable, scaleable, available 24/7 and above all we make it safe. In short we reduce it to practice in the real world. The software engineer depends on the computer scientist just as the mechanical engineer depends on the laws of physics. But there is another dependency. We feel it in those horrible moments of “I dunno”, when we reach out for guidance, wisdom and the courage to do the right thing, and we touch a void when we should be laying hands on practical wisdom: the stuff you get from experience. But life is cruel, it typically deals us experience long after we need it.

This is the life function of myth. It is the one way of gaining experience before you need it by inhabiting the experiences of others in the dramatic form of legend. Its true that myth is an oral tradition. It is unlikely that any of the events happened as told. In common with all history it is set down by people with an investment in remembering the past in a certain way – but that’s not the point.

Both wisdom and ignorance are among us like the mist on a river. From time to time they nucleate on a figure, a character of the dreamtime, imbued with virtues and vices, who moves through a story. The Iroquois on the Hudson, Agamemnon of the Iliad (refer end notes), an engineer in a cane field or the god A-Pur in a hallway. Character becomes plot and plot becomes legend and embedded in that legend is the right course of action for any imaginable human situation. I suspect that, on the dark night, I would have been at home in the bosom of my family by 6.00 pm, confident in a solid business decision well made, if the Iroquois had chosen to step forward from that darkened corner and advise us not to diminish ourselves with the rinky-dink tiger team option.

Here’s the trick: to extract wisdom from myth we must first abstract the essence of these timeless stories, find kernels of truth then project them onto our own experience. Abstraction and projection, the tools of the software engineer. We work with them every day, finding metaphors to express requirements and projecting them onto design structures imposing order on large bodies of code.

Myth in Action – a Case Study

So where does this leave you; sitting at your desk with a real world problem on your mind? For example, your project is behind schedule and the customer is complaining so your non technical boss (an accountant) has just told you to deliver a system that has not completed testing. You know that this is a bad idea. It will have destructive down stream effects: safety risks, business disruption, expensive code rework and a high probability of an unstable software product with a high cost of ownership (a condition we now classify as technical debt). You have choices: be a good soldier and do what you’re told or recognise this pathological management behaviour pattern for what it is and push back hard with compelling arguments. I was once caught in this exact situation and was unable to get the decision reversed. My protests that this behaviour was so bad that it had been documented raised eyebrows but, in the absence of an authoritative reference, there was no remedial effect. My subsequent research revealed the behaviour matched an ancient pattern: Deus Ex Machina, a plot device used by bad playwrights.

If I could have my time over, armed with what I know now, I would have pushed back harder not only with the reference but with the strident confidence of an Aristotle incensed by amateurish behaviour. Would it have made a difference? It may have. In that work environment (freeway construction) the most assertive alpha gorilla in the room often got his way. It’s hard to tell, but look at the cognitive dynamics. Here is a senior manager who by virtue of his position must have a huge ego, he must picture himself as a master of the universe wielding the forces of finance and technology to do great things – a person of historical importance. Out of left field comes Aristotle trash talking his early delivery strategy from a range of 2 1/2 thousand years. It’s bound to give him pause to think.

Further, be advised that an engineer educated in legend is never alone. You’ve got em surrounded. You come through the door backlit with the wisdom of many lifetimes. Think Aristotle (Deus Ex Machina) and Glenn Holliman fresh from the cane fields. Steeped in the tradition of legend, not only are you imbued with the right words to say but the courage to say them.

Birthing a Myth

Myth creation did not cease with the ancients. In fact it can be a potent management tool. People and situations pass into legend on a daily basis. If you’re a software development manager don’t suppress them – encourage them. In our context myth’s subliminal messages are essential to the sustained success of a software house. Why is this so? Simply because sustainability is driven by an emotional faith in Better and not by clinical fact-based decision making.

Your quest must be a matter of life and death

So if you’re birthing or propagating a legend, just tell the story, don’t tease out the meaning. Your listeners will value it more if they work it out for themselves. Don’t make it up, you don’t have to, life overflows with suitable material (refer: The Walker Street Massacre). But don’t be afraid of embellishments. It didn’t bother Herodotus when he wrote The Histories. He threw the “giant gold-digging ants of India” into the mix sending Alexander the Great on a fruitless search when in the neighbourhood. A touch of fiction can draw the truth into sharper relief and ignite imaginations with metaphors that become timeless. You can also add red herrings to entice your audience. Did the Fijian mill manager really utter the sublime explicative? It doesn’t matter, they’ll remember the pain more than the specific instruments of torture.

A compelling legend will naturally have a hero, a quest for some elixir, opposing forces in a shadow world, tests and trials culminating in a final ordeal, death and rebirth followed by a return in triumph to normality made safe by the elixir’s mystical qualities (refer Story for more details). Above all don’t hold back, legends that endure excite the visceral, they do not feed the intellect. Quests must be matters of life and death. The Iliad is redolent with the horrors of war, young lives snuffed out, crushed skulls and splattered brains, spears driven into men’s chests, warriors screaming in agony thrown from speeding chariots, gnashing teeth, chewing dirt, battlefields strewn with gore-covered corpses. All the while, Helen of Troy (the elixir) the most beautiful woman in the world watching from the battlements while armies fight over her.  Hard to forget.

The core mission of legend is engagement and self discovery –  to wrap an idea around an emotion. The stronger the emotion the longer the half life of the idea – until in the limit the idea purifies, maintaining its integrity when passed through all cultural filters on its way to humanity’s eternal lore. Evidence the Trojan horse, a metaphor that has been abstracted from an ancient story (The Iliad) and projected onto the dark side of computing technology (computer viruses). Here’s the thing: THAT STORY IS THREE THOUSAND YEARS OLD. Evidence the power of myth and the credibility of my assertion that we should take note and pursue application.

Application

As we have seen the role of myth is to provide guidance when all else fails. In operating a software house this applies to solving big problems, in my case an immediate need to radically improve software quality –  in the absence of experience, technical manuals, procedures or work instructions.

Legend even had a role in executing the strategy. Yes, we did promulgate the management policy that: “Standard operating procedures would be followed”, yes we did set ambitious targets for APARS/KLOC, but these alone were not the factors that caused it to happen. This is the thing about software houses; software is polymerized thought. If you want something to happen you’ve got to have a profound influence on the way people think. Policies are so much background noise but the images of Glenn in a burning cane field with a rabid mill manager suggesting sexual relations with his sister and the humiliation in the corridor at IBM stimulated the fundamental desire in everyone not to be diminished but to be good at what we did and to be recognised and respected by our peers. All this packaged with the core idea that, through this process improvement initiative, we were going to be Better – this is what resonated. And so I say to all software engineering managers:  take no prisoners, invoke the gods of legend, study legend, broadcast legend, abstract legend and project it onto your situation. Submit to nature – your natural instinct to tell stories. You will be rewarded.

Dedications

To the Iroquois: I have known your legend and for that I am a better man.

To the software engineer: we are here for such a short time, don’t spend a second of it in activities that diminish you.

To Glenn: I don’t know where you are mate, but I know you’ve got a pencil and I’m sure you’ve written that down.

…………………….

References

1. Raynor,M and Ahmed, M (2013) Three Rules for Making a Company Truly Great, Harvard Business Review, vol. 91 no. 4, April 2013, pp. 108-117
2. Rowlands, Mark (2008), The Philosopher and the Wolf, Granta Books
3. Grove, Andrew S (1996) Only the Paranoid Survive, Doubleday
4. Evans, Jules (2012) Philosophy for Life and Other Dangerous Situations, Random House
5. Humphrey, Watts et al (2010) Team Software Process Body of Knowledge, Technical Report CMU/SEI-2010-TR-020, [Online], Available: http://www.sei.cmu.edu/reports/10tr020.pdf [25 Sep, 2013]

…………………….

End Notes

The Iliad (a summary)
by Homer
Place and time: Troy, circa 1200 BCE.

Paris, a prince of Troy, has seduced and kidnapped the most beautiful woman in the world, Helen, away from Menelaus, a Greek; in revenge, Menelaus’ brother, Agamemnon, launches an attack against Troy to recover Helen. Fuelled by righteous anger (Paris was Menelaus’ guest when he seduced his wife) and allied with great warriors such as Achilles, son of Thetis the sea goddess, the Greeks are victorious after a 10 year war. They burn Troy, killing the men and enslaving the women and children. Paris kills Achilles with an arrow to the heel guided by the god Apollo. Paris is later killed by Philoctetes son of the Greek King Poeas. Helen, now middle aged, but still a beauty, is reunited with her husband Menelaus.

—————————————