Goofing-off for Innovation’s sake.

We’re working too hard to goof-off by playing with “better” ideas.

Innovation often goes by another name, it’s called goofing-off by some people. These are people with too little time on their hands and they should be pitied. In my experience these super busy people who also deride the value of “goofing-off” are rarely very creative or innovative. Innovation is a fickle little-god and demands sacrifices as it suits itself.

To illustrate the value and danger of goofing off, I like to think of metrics and minima and maxima. We can think of iterative process refinement as slowly seeking a local maxima of productivity. Like a turtle crawling along the ground we only see directly in front of us because our perspective is limited. Often in normal day-to-day life we’re limited in perspective by virtue of the hard work of living.

While our nose is to the proverbial grind-stone, it is easy enough to identify that certain tweaks to a process produce measurable improvement. When you make changes that cause some decrease in a highly valued metric the reflex reaction is to get that metric to climb back up right away. After all, your stock-price is a line and that’s a measure of your worth isn’t it? So why isn’t your Wiessman Score also similarly a measure of worth?

Optimizing some process to escape a local maximum might require passing through a global minimum.

To illustrate the subtle problem with metrics and scores, I like to use this analogy:

“Metrics are guiding stars. You sail your ship at night by pointing at a guiding star that gets you heading toward your destination. If, by some magic, you managed to actually reach your star you would be upset. That’s because your destination was NOT the star, your destination was Tahiti! Deep space doesn’t have those drinks with little umbrellas like Tahiti does, so we’d be very upset about this particular miracle.” — said by Shawn Hartsock at very geeky dinner parties.

The goal of 100% code coverage is not to actually achieve total coverage of code. In fact, the goal of code coverage isn’t to cover code at all. The goal of any unit test or quality assurance measure is to achieve the ineffible state of quality.

What is quality? What does quality look like? How tall is quality? How big is it? (Is quality doing anything this weekend? I have this boat and if quality wants to tag along, I’m game.)

Things like code-coverage, branch coverage, and code standards are necessary but not sufficient measures of this thing we call quality in Software. The actual thing we call quality requires more of an artistic license, a kind of curated judgement, or if you will a sense of refined taste.

So, in the case of Software Engineering and Development we may have to degrade code coverage, unit test coverage, or generally back-pedal in order to escape a highly refined sand-trap we’ve dug ourselves into. Pushing harder is like pushing a wagon with square wheels. We can push to delivery, sure, but if we delayed long enough to swap out for round wheels life would go so much more smoothly.

But, in fairness: when should you bother?

To retool a team from one set of techniques to another is NOT free. The cost is time and sanity which both can impact the bottom line eventually. The trick is to pick when to take the time to retool. Preferably, pick a “when” that has enough grace for your bottom line.

Laboring our square wheel analogy, if you were steps away from delivering that cart of goods then stopping even 5 minutes to swap the wheels is a very stupid idea. If, on the other hand, the length of time to retool versus the delivery date are at least an order of magnitude different then it is very stupid to not “goof-off” and experiment with new ideas. The difference in cost for exploration and research is great enough to justify the risk.

Goofing-off can pay off occasionally by helping you escape a local maxima or local minima in your process and technology stack. It’s not universally true that you should always entertain new ideas but it is vital you build into your process time and slack to allow for it. If you don’t, even with a continually refining process you can still get stuck in a sub-optimal situation.

Society and progress are built upon the excess productivity our new efficiencies produce. The continual refinement and production of excess capacity has historically enabled religion, philosophy, art, culture, and goofing-off. We aren’t efficient for efficiency’s sake, we’re efficient to give room to make life better.

So, goof-off in constructive ways! You might just improve your lot in life and the situations of many others.