Mind the Gap

While on a trip to London I spent a fair amount of time on the Tube going from here to there in order to see things, eat things, hear things or all three. I am absolutely fascinated by a mature railroad system where society has an indisputable dependence upon its presence, value and predictability. I've utilized trains in different parts of the States, Belgium, France, Spain and Portugal and am a bit jealous that passenger train systems are so prolific in other parts of the world, yet not so popular in the States. I've had good experiences on every train excursion to date, but something during the London Tube experience stuck with me -- it was the wonderfully British accented voice telling me to "mind the gap" between the platform and the train itself so I wouldn't fall into the void and die a grisly death. Until then, I had not recognized a gap worthy of conversation even existed, let alone one which could contribute to my demise. Now I can't stop thinking about it. Well done wonderfully British accented voice recording. I'm still minding the gap though there is not a train within miles. The difference between what I thought was important and what someone called to my attention did not match.

What this brings to mind is the oft-discovered-in-arrears delta between what someone thinks they know, and what they actually know. There is often an unrecognized gap -- sometimes built on inexperience, hubris, different planes of existence, or carelessness. Unfortunately, or fortunately depending upon your outlook, we often discover the gap through error.

How long will it take to complete a particular project or task? Unless you've personally performed the task before, have parallel experiences from which you can extrapolate, or have at your disposal a panel of experts who have personally performed this work or have parallel experiences from which to draw an aggregate postulate, you simply do not know with precision. You can however, surmise or posit a theory --- and this brings into conversation the idea of relative sizing. You may not know exactly how long something will take, but you know if it is larger or smaller than some other form of personally derived measurement and can then extrapolate, relatively. Of particular enjoyment to me, I watch with interest those people who are not actually involved in the situation and neither have direct experience, nor parallel experience, but cannot seem to help themselves from espousing what must surely be a correct estimate anyway. Gap, indeed!

What I tacitly know is built upon first-hand knowledge gained from personal experience. What I think I know is built upon extrapolation and/or perception referential to personal experience. There is a gap. When do I find out there is a gap?

This abstraction is likened to watching children grow. At early ages, when the ball disappears behind the couch, the child assumes it is gone. However, as the child ages, based upon aggregate data collected through personal experience in the past, he or she deduces that the ball must surely be behind the couch even though not visible. There is a gap. In order to eliminate the gap, one must first crawl behind the couch and find the ball thereby affirming the original deduction. Ball here. Ball gone. Crawl behind couch and see ball behind couch, or see someone pick up ball from behind couch and extrapolate. Now, the next time the ball rolls behind the couch, I know it is there even when I cannot see it. Done.

At what point did the child recognize there was a gap between what he saw and what he knew? Was it a choice or an accident to make this recognition? Was discovery of the ball behind the couch a by-product of curiosity or chance alone?

Let's go back to the London Tube. I did not recognize, nor give thought to the gap because I was pre-occupied with other goals, and working on a set of assumptions:
  1. I assumed I correctly knew how to move from platform to train;
  2. I assumed I correctly knew how to be safe whilst making the transfer;
  3. I correctly assumed I needed to board the train prior to departure; and
  4. I correctly assumed I needed to avoid getting caught in crowd congestion or door movement.
Nowhere in this line of thought did I overtly identify minding the gap. Had the wonderful British accented voice not called out the point of "minding the gap" to me, when would I have made the observation? After I tripped, fell through or got a foot stuck? Or maybe after I saw someone else trip, fall through or get their foot stuck?

How often do people think they know something and fail to recognize there is a gap, perhaps canyon, between what they know and the way things actually exist? Unless we purposefully ask ourselves this question on a regular basis, we'll never know until we trip, fall through or get a foot stuck. More difficult for all involved is the fact that leaders often make decisions based upon what they think they know which may or may not match reality. This brings up two interesting observations:

  1. Given that leaders are often abstracted out from the ground-level line of work, it would be easy to feed a leader disinformation, falsity, or misrepresented facts in order to exploit the unrecognized gap; and
  2. Given that leaders are often abstracted out from the ground-level line of work, it seems logical there should exist one, preferably more than one, team member responsible for keeping the leadership accountable to reality.

Let me explain.

If there is a gap between what a leader thinks she knows and what she actually knows, until it is discovered or pointed out, she will make all forward moving decisions built upon the perceived information available in her mind. Seems like this gap may be a normal part of life, yes? Is the gap between reality and actuality, i.e. knowledge deficit, acceptable to you were a neuro-surgeon removing tumors from your brain? How about perceived versus actual altitude during a commercial jet landing? How about perceived versus actual facts while you're on trial for a crime you did not commit. Gaps are important. Whether we recognize them with immediacy is the criticality.

Flashback: What if during neuro-surgery a nurse pointed out that the tumor of interest was located at X and Y axis coordinates? Fact or fiction? Misinformation or disinformation? What if the surgeon modified his actions based upon the new information assuming that the nurse is likely more accurate? Or, what if the surgeon ignored the nurse? What we think we know and what we actually know should be questioned.

IF you were to argue that your job, responsibility or life were quite less impacting than that of a neuro-surgeon or commercial pilot OR that due to your own circumstance the binary decision to be exact is less relevant; THEN I argue you are negotiating shades of mediocrity with yourself -- which is yet another reason for accountability to the gap. Maybe you believe being inexact is okay; and maybe the guy who has to live with your world view and decision disagrees with you.

It is my opinion that all leadership requires accountability; not just for moral and ethical dilemmas, but also for corroborative fact-based assessment and decisioning. In fact, it is because of the gap between what we individually and collectively think we know versus the risk of a differing actuality that we should question leadership, decisions and direction. However, it is not just leadership that requires said accountability, but anyone with a supposition or opinion. Unless you crawled around behind the couch and personally verified that the ball is there, how do you know with unquestionably surety? Unless you can indisputably evidence that your perception is in fact reality, how can you confidently march forward in a care-free stride? How do you even have an argument?

There is a valid argument that we do not live long enough on this earth to personally verify everything, and that there are some things that we choose to accept as fact, whether through faith, extrapolation or juxtaposition of multiple elements.

The important thing to recognize is that there is a gap between what you think you know and what you actually know. Will you mind the gap in advance, or will it only be after you've missed the train or been run over by it?

"Agile Journal" Interview, June 2008 in Toronto

This is a 10m interview clip of me whilst at the Agile 2008 conference in Toronto. Patrick Egan, of eminent fame in the software engineering community, performed the interview for the Agile Journal with the purpose of exploring my (and that of many others) views on Agile evolution and permeation through the industry. I first learned of and interacted with Patrick over a decade ago via the configuration and change management communities. He has maintained his affiliation and leadership in the software community, in particular through CM CrossRoads, and we are all the better for it ... continuity.

Good Enough: Is This Really Mediocrity in Disguise?

Self-evident perhaps, there seems to be a very simple argument at hand regarding good enough software and how this statement alone may or may not stimulate right behaviors out of teams:

  1. Is choosing 'good enough' a form of identifying when to stop spending time, money and effort contextual to the return on investment; or

  2. Is choosing 'good enough' an excuse for choosing mediocrity?

For those who know, and then choose, to look at software through the lens of cost of acquisition, cost of ownership and return on investment the idea of 'good enough' is a decision on spending money versus making money. Even then, pride of ownership and contribution challenges many people because doing their best may exceed the minimally required cost of acquisition, i.e. to put icing and sprinkles on pastries may be the extra mile when a plain pastry may have been good enough.

This brings into question the conflict of the 'art of'' software delivery versus pure solution engineering.

Were I to have a bakery, I would want to make the indisputable best pastries in town while not only making profit, but ensuring the reputation I create is one that keeps me in demand through the coming years. If I concentrate heavily on profit margin, then I may focus on minimal investment (internal focus). If I concentrate on being the indisputable best, then I may focus on my competition and the perceptions of others (outward focus). To balance this out, I focus on a target cost and margin coupled with a target audience and I arrive at a somewhat algorithmic approach to balancing one with the other. Notice I said somewhat given the predictability of people lay in question (maybe I inadvertently started a pasty business in a vegan town, or failed to recognize people only visit this town in the summer).

Were I to desire scale commerce, then I'd additionally concentrate on cost of ingredients, volume of ingredient use per batch and individual pastry and may lean toward margins as a priority. Were I to conversely desire community specialty boutique status of greatness, value and artful innovation/creativity, my focus may lean toward 'going the extra' mile...suggesting I may use more icing, more sprinkles, serve larger portions, and spend more time on presentation in general.

And why do some restaurants stay in business to our mutual surprise, and others go out of business -- again to our mutual surprise? Is the answer always location, location, location? What if I have a great location, but I chose to focus on minimalist effort for maximum margins in a community that prides itself in having the best of the best?

If running a bakery or restaurant were math alone, accountants would be restaurant owners.

And then back to software... is delivering software so easy as identifying cost and stopping the work when the cost is met?

What if "good enough" conflicts with "pride of ownership"? How does that get reconciled? What if a buttered croissant is good enough, but you're really a frustrated pastry artist at heart -- longing to make that one, artfully innovative new fahrvenugen? Or, what if you personally have no issues with buttered croissants, but the staff you hire wants to do more? Where does 'team' come into the conversation versus just employer v. employee? How does one stimulate pride of ownership and innovation without breaking the bank along the journey?

My argument is this:

Delivering software is not only engineering, it is art.

If delivering software were anything less than art, anyone with an opinion and a calculator would be successful doing it. Standing in a garage doesn't make me a car anymore than someone choosing hourly rates over quality of work makes them a successful problem solver from the perspective of a customer. I find it hard to argue that math alone is a valid solution delivery pursuit given the condition of the United States financial market. And since we know failure statistics for software projects around the world to be very high, we know that opinions and calculators simply are not good enough -- alas, but the definition of success and failure is relative as well. To know what tool, language or framework to use per situation oftentimes comes down to objective subjectivity in selection. An art? One person may be perfectly talented in Java whilst another in .Net. Thereafter, predisposition influences selection. And then how Java or .Net is implemented is unique to the implementer. Again, art.

To use ten team members or eight.
To use on-shore, near-shore or off-shore.
To negotiate based upon rates or experience.
To start a business, stay in business, and be successful.
To blend a combination of elements making a unique solution?

I believe the definition of 'good enough' is relative to the definer. I believe the definition of mediocrity is as well. I also believe that some people simply do not understand the art of solution engineering and hide behind the argument of 'good enough' as a defense for skill deficit. One person's 'good enough' may be another person's 'mediocrity' without either knowing their definitions vary -- except when all members of the team sit beside each other and pair program using test driven development. The definition of greatness becomes a community pursuit and each person's definition of great is challenged frequently and often. Not so when teams of technologists sit in their own cubes/holes/closets and solution on there own. And no, despite wonderful fractals generated by mathematical algorithms, the pure definition of art does not request a spreadsheet as it's pre-requisite to existence. Pure art ordinarily involves human intervention, ingenuity, interpretation, adaptability, vision, execution contextual to individual skills, and sometimes a bit of attitude.

How about we change this conversation into simple problem and solution statements we can all relate to?

  1. What is the business problem we need to solve?
  2. What is the simplest possible solution we can use to solve this problem?
  3. Do your best at every opportunity and go home proud of your contribution, daily.
  4. Get the solution out there, get immediate feedback and invite change.

When I know what business problem I need to solve and refine it as I learn more, I concentrate on the definition of done. When I search for and choose the simplest possible solution, I not only meet the criteria of minimized cost of acquisition, but minimized cost of ownership and compressed return on investment windows by default. When I ask people to do their absolute best in every opportunity and to go home proud every night, my challenge is to each individual contributing to a team. I don't have to define mediocrity because I don't believe anyone proudly chooses mediocrity. And when I get the solution to market as quickly and simply as possible, I'm equipped to get immediate feedback so that I can change with the market demand. Paired programming, test driven development, continuous integration/test/feedback, short iteration windows, and clear business problem definitions (user stories) and definitions of done (acceptance criteria and test fixtures) combinatorially define good enough and mitigate mediocrity through team synergy. The focus is on the behavior, not the dollar. And the behaviors are ironically subjective.

Deciding if a business problem statement is in its simplest form is subjective and relative. And deciding if a solution is in its simplest form is subjective and relative. Responding to market shift is again subjective and relative. And deciding if this article entry covers the topic well enough is subjective as well.

Maybe this explains why there is so much subjectivity in delivering technology solutions. The end-users are usually humans and we seem inordinately challenged at agreeing whether there is first a problem and how it gets characterized, let alone what the solution may need to be, if any at all.