Blog posts tagged "just ship"

“They can even stop when they have a map that is just good enough.”

January 28th, 2012

There’s a hilarious answer to the question Why are software development task estimations regularly off by a factor of 2-3? floating around now. Hilarious, deeply knowing, but not terrible accurate or actionable.

But buried in the comments was this gem from Neil K, which I’m going to quote, in it’s entirety, for truth (Neil has, after all, seen more sausage getting made at more of the places whose tools you use then nearly anyone):

This is really good, but if I can offer a suggestion — the analogy could be even more apt with a slight shift. Currently it only shows how people go wrong when they develop software in a naive way — by starting at the beginning, and coding each step to final quality, in order. The story, as written now, makes it look like writing software is just an impossible slog and nobody can do it.

The truth is, software is research. It’s a matter of discovering the solution, not plodding through it. This is implicit in your story, because they keep encountering unexpected problems. But let’s make it explicit.

Imagine, instead, that our intrepid pair is charged with mapping the coastline of California from SF to LA. Mapping is more like software development because it involves discovery, and getting things right at multiple “points”.

The naive mappers start off from SF and it all fails exactly as you outline. A more clever pair of mappers instead decide to hire a boat, and map just a few points on the coastline precisely, just to get a rough estimate, and to survey the coastline for the tricky places. Then they know where to apply their efforts — an intern can be hired to pace out some of the easy bits, and a team of well-equipped hikers can be brought in to handle the hard parts.

They can even stop when they have a map that is just good enough.

Shipping, it gets harder

May 7th, 2011

Love this quote from Borthwick regarding and shipping:

“I ran a new product development group within a large company and I would like to dispel the simplistic myth that big companies don’t innovate. There is innovation occurring at many big companies. The thing that big companies really struggle to do is to ship.”John Borthwick –

People ask me why I focus so relentlessly on shipping as opposed to the rest of the software development life cycle. In part because it’s hard. It’s often the hard problem. And it gets harder the longer you do it, aka it gets harder the more important the thing you’ve built is.

The Brooklyn Problem

May 5th, 2011

I was honored to speak as part of the rapid fire keynotes Thursday morning at Where 2.0 (4/21), and gave a brief (even briefer then originally planned) talk on “The Brooklyn Problem”.

The slides:

The video:

Folks have told me they enjoyed the talk, and found it inspiring and informative, which is immensely gratifying.

I was personally frustrated with myself as I wasn’t as prepared as I like to be, and I made a number of last minute cuts from the talk that made it feel more disjointed then I liked.

This can be summarized in the #protip: When the organizers give you a chance at a dry run to get to know the stage and the equipment, do it!

Additionally I didn’t get to talk about the work of Aaron Beppu who recently joined our search team tackling relevance ranking, did the bulk of the backend work on this project as his bootcamp project, and whose final implementation is significantly more complex and interesting, or Fred Blau, who is currently working on our internationalization effort, but who rewrote our auto-complete implementation to use sequence ids instead of timing for a much smoother interface.

dirty hands

April 5th, 2011

Now that’s interaction design! (and my favorite take on the work we’re doing at Etsy.)


January 20th, 2011

Recently was given an axiom which turns out to be folks engineering wisdom, namely:

Optimizing a system requires sub-optimizing the subsystems. Conversely optimizing a subsystem sub-optimizes the global system.

Chewing on that as it relates to technology and organizations.


(In particular I was thinking about the related corollary this afternoon, namely, “We work hard to be able to be this dumb.”)

Dinosaur Development

September 27th, 2010

A friend recently described the going off and working on software for $N days/weeks/months and coming back with a finished projects as “being a dinosaur”.

The classic, anti-social highly focused development process as totally maladapted to our modern systems, tools, life cycles, and dependencies as the “great lizards” of old. I’m going to steal that.

It’s the exact opposite of Just Ship/Move Fast.

Fred’s wrong (or quoted out of context)

July 22nd, 2010

[Twitter breaks] because “it wasn’t built right — Twitter was built kind of as a hack and they didn’t really architect it to scale and they’ve never been able to catch up.” – Fred Wilson

This is wrong.

Twitter wasn’t built as a hack, it was just built. The way you or I might build something new, in a couple of weeks, with some databases, and a couple of cron jobs, and a daemon or three. If they had built it [portentous voice]TO BE TWITTER[/portentous voice] they would have failed.

Scaling is always a catch up game. Only way its ever worked. If you never catch up then something isn’t working, but it isn’t original sin.

  • July 17, 2010

    Tom Taylor: you’ve either shipped or you haven’t.

    “You’ve either poured weeks, months or even years of your life into bringing a product or a service into the world, or you haven’t. If you have, you’ll know what I’m talking about. You’ll have flicked a switched, cap deploy‘d, or flipped your closed sign to open, and just waited – holding your breath for whatever happens next.”

    + 1. (Aside )

Try Coding Dear Boy

September 29th, 2009

Several times a week I get an emails like, “Can you explain how Flickr does XYZ? I’m hoping there is a nice packaged solution for this.”

XYZ can be anything from “draw tag maps”, to “click in place editing”, to “scale MySQL”.

And I’m always a little baffled as to what to respond.

Until I realized what was going on.

Laziness Impatience Hubris

This is the dark side of the geek virtue of laziness.

The belief that if one just thinks hard enough, or cleverly enough, that problems will have an “elegant solution”. And by “elegant” we mean a solution that doesn’t involve much code. (elegant, such a tricky word, it can also mean writing tons of code for problems that will likely never manifest) And by “think hard and clever”, a good short cut is probably just be to ask someone.

So I’ve come up with a response that looks something like:

“We generally try do the dumbest thing that will work first. And that’s usually as far as we get. Almost everything we do is pretty straightforward, and as such is well documented around the Web, sometimes by us, generally by others. And when we do get fiendishly clever, as we do now and again, it’s usually a highly tuned (read idiosyncratic) solution for the problems we’re trying to solve.”

Method Acting

But what I want to say, in the spirit of the great Laurence Olivier on giving advice to Dustin Hoffman, “My dear boy, why don’t you try coding?”.

Duct Tape

Which is not to say I mind getting these questions, I love talking about this stuff, it’s why I do it. And it’s often amusing to give the, “This is how we do it at Flickr, no really” talk.

But at the end of the day its 0.1% compsci, 0.9% clever ideas, and 99% duct tape. (btw Joel’s The Duct Tape Programmer is a meditation in similar vein)