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.
Art.
To use on-shore, near-shore or off-shore.
Art.
To negotiate based upon rates or experience.
Art.
To start a business, stay in business, and be successful.
Art.
To blend a combination of elements making a unique solution?
Art.

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.

No comments:

Post a Comment