DevOps Zone is brought to you in partnership with:

I'm a Brooklyn-based entrepreneur. I'm passionate about turning data into understanding. George is a DZone MVB and is not an employee of DZone and has posted 9 posts at DZone. You can read more from them at their website. View Full User Profile

Broken Tools - Liveblogging LinerNotes.com

03.02.2013
| 1643 views |
  • submit to reddit

Equipment in action operates in an inconspicuous usefulness, doing its work without our noticing it. When the tool fails, its unobtrusive quality is ruined. There occurs a jarring of reference, so that the tool becomes visible as what it is:”—Graham Harman [1]

Last live-blog, I made a plan to launch. Just the day before, I talked about how often planning goes astray. And unsurprisingly, it’s only taken two days for my plan to get off track.

This plan is about broken tools. But more broadly it’s about being sucker punched by the unexpectable. Luckily I got off pretty easy this time, but the punches come hard and fast, and they will for as long as I’m in this business.

Why write about it now? Because a lot of stuff has broken in the last few days. I’ve had to spend so much time putting out fires that my self-imposed deadline of “pushing the button” by tomorrow is probably not going to happen.

Some of the breakage has been minor and some has been major. All of it has been completely typical.

Minor example: I got a letter (delayed in the mail) urgently requiring me to scan and email a document. My scanner broke that same day. So I had to waste 20 minutes on the phone with Lexmark’s absolutely dismal customer before tracking down a fax machine in a bodega.

Major: The virus I thought I beat last week has returned, leaving me feverish and mealy-minded. So I’ve been operating at 25% productivity today as I try to force my mind to think enough thoughts to figure out why ElasticSearch has abruptly stopped working.[2]

Both of these inconveniences were effectively unpredictable.  Both siphoned off real time. And like a running back’s shoe falling off mid-stride, they made themselves perilous to ignore and shattered the precious “flow” where technical productivity hides out.

As you saw on Tuesday, I tried to make conservative estimates for how long each step of preparation would take. But I’ve already handily blown through my margins. The problem is that the time a task requires is not normal distributed – it’sheteroskedastic. In other words, nine out of ten times it will take me 15 minutes to get to Union Square. But the tenth time the train will break and it will take an hour. So when I’m deciding how early to leave for a meeting, my only options are to leave an hour early (and spend hours each month alone in Starbucks, guarding my seat from 14 year old girls with their cinnamon spice lattes), or to accept that once in a while I’ll be offensively late.

Doing the former is the equivalent of buying so much health insurance that you can’t afford to eat. It’s just not practicable. On the other hand, the person you’re late for will really be offended: people tend to weight one negative interaction about as much as a dozen positive ones. I once heard noted VC Brad Feld say that he would not invest in a company unless every interaction was better than the previous one.

But think about the paradox there: the only teams that never fail are either much too conservative, absurdly lucky, or outright lying.

For me, lying is automatically off the table. And my luck is stubbornly resistant to dark magic. But I haven’t figured out another good solution. It pains me to miss my launch target, especially so soon after I’ve posted it publicly. But the alternatives (don’t be transparent, or power through and make myself sicker) seem even worse.

Entrepreneurs build with fragile tools. They’re all we can afford. But earning the confidence of employees and partners seems to require projecting a superhuman façade.

How do you reconcile that tension?

[1] I wanted to start this post off with a quote from philosopher Martin Heidegger, since I’m stealing his idea about tools. But I couldn’t find a direct quote that would require less than 500 words of jargon unpacking, so enjoy this secondary source.

[2] I skipped yesterday; these posts are taking about 75 minutes / per, so a rigid daily cadence is clearly not going to happen.

[3] Backward incompatible version upgrade, plus forgetting to update the cluster name in code upon spawning a new cluster.

Published at DZone with permission of George London, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)