Shut up and ship

The startup community operates in a world of “get out of the building.”  Of “write more specs“.  Of asking “should this project even be built“?  This converges on a culture of “everything except the code.”  Have meetings about the featureset.  Write documents about the featureset.  Argue with other developers about the design.  Think about the best tools to use.  Watch a bunch of videos about how other people solved the problem.

Is it good to write specs!  Yes!  Is it good to talk to customers?  Yes!  Are there companies we’ve all been a part of that spent seven figures building something nobody wanted?  Yes!  Does that mean that every single design decision in your pie-in-the-sky hypothetical non-existent product needs its own flamewar, customer approval, and/or design review?  No!  Does it mean that you are doing something wrong if you spend two weeks building something without any customer validation whatsoever?  No!

Eric Ries, Steve Blank et. al. don’t actually advocate doing 100% feedback-driven decisionmaking.  They advocate things like “finding the right balance” and “[initially] proceed[ing] with Product Development, with the feature list driven by the vision and experience of the company’s founders.”  The problem isn’t with the original teachers, it’s with the followers.

I’m talking about testing 41 shades of blue.  (Is testing good?  Yes!  Is it a replacement for design?  No!)  About not building anything until you know people will use it.  (Is market research good?  Yes!  Is two days of market research good on a project that takes two days to build?  No!)

Somewhere along the way, somebody has decided that if a little bit of talking about software is good, than a lot of it is great!  And this gives ammunition to the classical bikeshedding scenario:

It was a proposal to make sleep(1) DTRT if given a non-integer
argument that set this particular grass-fire off. I’m not going
to say anymore about it than that, because it is a much smaller
item than one would expect from the length of the thread, and it
has already received far more attention than some of the *problems*
we have around here.

The sleep(1) saga is the most blatant example of a bike shed
discussion we have had ever in FreeBSD. The proposal was well
thought out, we would gain compatibility with OpenBSD and NetBSD,
and still be fully compatible with any code anyone ever wrote.

Yet so many objections, proposals and changes were raised and
launched that one would think the change would have plugged all
the holes in swiss cheese or changed the taste of Coca Cola or
something similar serious.

One of the reasons that this happens is that it is a lot easier to have an opinion than it is to implement it in code.  Just thinking about me personally, I probably have five opinions about someone else’s code for every block of code I write myself.  As Kamp said in 1999:

The second part of my wish is more emotional. Obviously, the
capacities we had manning the unfriendly fire in the sleep(1)
thread, despite their many years with the project, never cared
enough to do this tiny deed, so why are they suddenly so enflamed
by somebody else so much their junior doing it ?

Phrased alternately by an anonymous hacker in 2012:

Now say by some strike of holy luck an actual person who can accept pull requests comments, I see this all too often. “Oh, I was gonna implement this in the near future… Pull request closed.”

Why not accept the pull request, release, make the patch when you have the time, I know people are busy, then release again. Rather than taking someones elses time throwing it on the floor and giving it the worth of your future promise of sometime. Oh, and what’s worse I don’t think I can think of one, NOT ONE time that a person has actually gone back after closing a feature where the work is done and done it themselves.

One of the things that set me off on this tangent today was this article on HN about what’s wrong with the Linux desktop.  It’s a reasonable article.  And then 327 people wrote a paragraph or two about what they think is wrong with the Linux desktop.  How many of these 327 people submitted a patch that improved the state of the Linux desktop recently?  I would be surprised if it’s in the single digits.  The world doesn’t need more people flamewarring about what’s wrong with Linux.   It’s not going to help.

Here’s a reality check:

GTK has 1 person working full-time on it (me). Glib doesn’t even have that. I think evolution is in a similar situation (a complete email client).

I actually took a look, and in the amount of time it took 327 people to pile on with their opinions, a whopping one person committed to GTK, 4 people committed to Linux 3.6, one person committed to ALSA, etc.  It’s entirely possible that there are one or two comments in the thread from people who actually know something about the real challenges of fixing Linux who have seen them firsthand–but if so, those perspectives didn’t bubble to the top.  What did bubble to the top was relatable, “one time Linux didn’t work for me” or “one day I switched to OSX” anecdotes that are easily consumed, but produce exactly zero meaningful improvement in any specific dimension.  I can’t find any comments that start out “Back when I was a window manager maintainer, here was the problem: …”

I am not saying that everyone has to have patches in the core Linux desktop (I don’t) or that they have to go through that rite of passage before having a valid opinion.  All I’m saying is don’t spit into the wind when you can build a windmill.

If it’s true that it’s easier to form an opinion about software than to write it, it strikes me as fascinating that we spend so much time in the startup literature emphasizing forming the correct opinions: talking to customers, collecting feedback, doing marketing, and comparatively little time emphasizing just plain old coding.  I mean–of course collecting feedback is important!–but most developers (who, contrary to popular belief, are not all social wallflowers) will do some amount of feedback collection without any prodding.  Some of the most productive programmers in the world spend 2-6 hours per day actually coding.  What do you think they do the rest of the time?  Talking about code they have written or are about to write, listening to someone else talk about code that they have written or are about to write.  What do you think they are doing at the software convention?  What do you think they are doing at a meetup each Tuesday?  Software developers don’t need a whole lot of prodding to collect feedback.  Maybe they need some prodding to collect better feedback.  But there is no stereotypical software developer who sits for hours, eyes glazed, a stack of pizza boxes in his wake, with narry a thought of the ultimate customer.  Not a case.  Not a failure mode that is worth our concern.

I’m not saying “Have no flamewars.”  I’m saying “Have fewer flamewars” or “have better flamewars” or “have shorter flamewars.”    I’ve ended up in a lot of arguments lately where the conversation has been “Consider a hypothetical tool that does something really complicated that I can’t explain effectively in three sentences.  Would you use this tool?  Why or why not?”  There’s a high probability of bikeshedding with that, and there’s a high probability of people saying “it should be like this instead” when really, they’re not going to use the thing either way.  You can get meaningful information out of this conversation, but usually not after wandering through the wilderness of “what do you mean by lower level of abstraction” and a bunch of other stupid arguments about nothing in particular.

Now consider the alternative: spend a week prototyping the tool, build a three-minute demo of the tool, then have the flamewar.  Now the conversation is: “Consider this actual tool that does a well-defined thing I can demonstrate for you.  Have you been successfully convinced to take tangible action and use this tool right now?  If not, in what way can I evolve it such that you will use it?”  This is still feedback-driven development; it’s still soliciting customer buy-in and doing MVPs and ticking all the right process boxes.  It’s just a healthier, lower-bikeshed-factor, well-defined, more actionable kind of conversation that is more likely to lead to helpful outcomes.  You can still have 52 flamewars a year, and they can be good flamewars.

One of the PMs at Microsoft famously had the motto: “Decisions in ten minutes or less, or the next one’s free.”  I spend a lot more time than that either making decisions, or justifying decisions that have already been made.  And there’s value in questioning my assumptions.  But there’s also value in just shutting up, shipping something that works, and going back and fixing it later if it turns out it was wrong.

Another technique that has been somewhat helpful to me is collapsing an argument tree into a flat list of positions.  At least for the first N hours of a flamewar, you get 90% of the value out of the first couple of responses, rather than the rebuttal and counter-rebuttal and counter-counter rebuttal.  So if your goal is flamewar efficiency, I have found it effective to round-robin and hear everyone’s best first argument and then immediately table further discussion.

I guess the point of all this is to say that I have too many flamewars, and I don’t ship enough actual stuff.  There is a big impedance mismatch between talking about code and writing it: coding is, for the most part, better than talking about coding; but talking about coding is a lot easier and more fun.  And the result is that the ratio of opinions to patches is about 100:1.  And as fun as that is, I would rather be the guy who writes software that some people use over the guy who wins the contest for most convincing explanation of why more people don’t use it.  There’s obviously nothing wrong with being able to do both; but with an impedance mismatch of 100:1 I don’t think we’re in any danger of that.

---

Want me to build your app / consult for your company / speak at your event? Good news! I'm an iOS developer for hire.

Like this post? Contribute to the coffee fund so I can write more like it.