
Speed as a Habit - kanamekun
http://firstround.com/review/speed-as-a-habit/
======
calinet6
I take offense to _idea_ of speed as a priority, though not necessarily to the
whole article.

> All else being equal, the fastest company in any market will win.

All else is never equal when speed is the driving factor. I have _never_ seen
a company execute well while pressuring for speed.

It's significantly more important to think about systems. What is the
cooperative source of your speed? What are the barriers to making good product
quickly? What allows us to make faster decisions?

Invariably, without fail, unequivocally, the answers to these questions—which
are sources of speed, quality, and market fit—lie in the systems that compose
a company. Not systems as in slow methodical heavy processes, but systems as
in a clear understanding of how things are connected and how to continually
improve how they work.

Start with systems, then you can go fast. It's ludicrously dangerous to put
the cart before the horse. Granted, much of this article dives into detail on
how to make things run smoother in order to go fast—that's great, but if you
make it the primary focus, imagine how fast you could go.

Speed... a noble goal, but as W. Edwards Deming said, "By what method?"

~~~
blowski
I agree with you. Being first (or even early) to market is obviously an
advantage, but it's neither necessary nor sufficient for success, as countless
examples show. "The second mouse gets the cheese."

In a market with rapid growth and technological change, sometimes it can even
damage your prospects. For example, MySpace found themselves dominating the
market while it was still small, and for whatever reason, wasted the
opportunity. Facebook learned from their mistakes and took control of the
market MySpace had helped to create.

~~~
joshuapants
Also: Tablet PCs vs. iPads.

------
bsder
> Speed is a defining characteristic — if not the defining characteristic — of
> the leader in virtually every industry you look at.

Not even close.

Apple was _WAY_ late to the MP3 player party. AltaVista was way ahead of
Google, but DEC marketing ("DEC has it now, but you can't have it.") couldn't
sell water to a man dying of thirst in the Sahara. Android had far better and
faster competitors, but it brushed them aside.

In addition it is _well_ documented that the first company in a category takes
all the arrows while the second company makes all the profit.

Things rarely need to be done that fast.

~~~
enraged_camel
>>Apple was WAY late to the MP3 player party.

If you think of the iPod as an MP3 player, sure. But I think Apple tapped a
brand new market with the iPod: the "fashionable gadgets" market. Arguably,
that's the main reason it was incredibly popular.

~~~
Obi_Juan_Kenobi
I'd say the Walkman gets that honor, if not some other product.

The iPod was popular because it was the first practical MP3 player. Take a
look at the competition:

[http://www.examiner.com/list/five-portable-mp3-players-
that-...](http://www.examiner.com/list/five-portable-mp3-players-that-arrived-
before-the-ipod)

You've got reasonably sized devices that could hold a few dozen megabytes, or
impractical tanks that had real capacity. The iPod was the first to do both.
It also had a user experience that was quite painless.

------
Animats
He quotes Patton. It's worth remembering that Patton was not in overall charge
of the war in Europe. Eisenhower was. Eisenhower, who was a logistics officer
by training and background, had a basic plan for winning in Europe - build up
a mountain of resources so large that the Allies could roll over any possible
opposition. Which is what happened.

Eisenhower put Patton into play when a part of the operation needed speed and
violent execution. Eisenhower took Patton out of play when it didn't.

~~~
avn2109
This is super interesting, where did you learn about it?

~~~
Animats
Any good history of WWII covers this.

"Patton", the movie, shows it from Patton's perspective.

"You will not find it difficult to prove that battles, campaigns, and even
wars have been won or lost primarily because of logistics." \- General Dwight
D. Eisenhower

More detail than you probably want - Gen. George C. Marshall's comments after
the war.[1] See p. 8 of the transcript.

A more modern perspective - "Moving Mountains", a book by Gen. Gus Patronis,
head of logistics for Desert Storm. How the U.S. Army built up a massive force
in the middle of nowhere and then won a war in four days. This is a useful
perspective on "speed". If you want to go fast, having massive resources
available makes it work.

[1] [http://marshallfoundation.org/library/wp-
content/uploads/sit...](http://marshallfoundation.org/library/wp-
content/uploads/sites/16/2014/05/Marshall_Interview_Tape13.pdf)

------
dbg31415
Well, so I can see this article being twisted all over the place.

It's hard enough to get proper time for planning technical projects without
this kind of crap.

Guess what, planning time does save time and lowers your cost of ownership.
ROI-wise, planning time is the best gift you can give your project.

But... then someone is like, "Speed, I hear speed is good... move faster.
Dependencies... fuck 'em... I don't understand 'em anyway so fuck 'em. Let's
just go as fast as we can and we'll worry about everything we should have
worried about up front over the next few years after all our devs quit because
they're tired of working on shitty code that was rushed through."

This article so rubs me the wrong way. "Technical debt? What's that?!"

Anything worth doing, is worth doing right. To the best of your ability. Doing
things right takes time. Take your time, do things right.

~~~
mschip
You read my mind. Points from this article need to be taken in context..
especially all the examples from Google. It's one thing to say 'Do it faster!'
and have unlimited resources at your disposal (Google), but it's whole
different ball game to harp on your 5 member startup. One adds hours via
bodies and the other ruins work/life balance. That can really set a negative
tone for an early startup trying to attract talent.

I enjoyed the 'GM is slow' comment. While that may be true in terms of
innovation, it is the opposite when it comes to manufacturing. I've worked in
those plants where the 'speed above all else' sentiment is eerily similar to
this article, and is largely the reason I chose a different career path.

The one thing I take away from this is the accountability perspective. It's ok
to ask why things will take the amount of time projected. Things often do get
tacked on that don't need to be.

~~~
dbg31415
I was going to write up a bit of a rip on this as well:

> All else being equal, the fastest company in any market will win.

So, that's why we all still use AOL? And why Microsoft never had to worry
since it built Office? Why PayPal squashed Venmo? The point is really that all
else are never equal. Speed to market is A factor, but it's not the only
factor, or even the most important factor today. Look at Box, vs. Dropbox, vs.
Copy, vs... The market is big enough for multiple identical services. Users
pick the one that works the best for them.

And I certainly agree asking questions is a GREAT way to start documenting all
the stuff that has to go into a project. I'd add a bullet point, "Way more
hours than I want for... explaining why setting up Vagrant is important...
explaining why unit tests save time, for the 900th time... explaining why QA
is needed..."

Things don't often get tracked that ought to be, but PLEASE do not send more
meeting requests to your entire dev team asking them to justify to marketing
or sales why we need the basic steps we ask for.

(This article hits a bit close to home today, as I'm literally in a meeting
with 15 people where only 2 people are talking and I literally just had to
defend QA marketing guy who clearly doesn't get it. And the topic... "How we
can organize our team to be more efficient.")

~~~
anthony_d
Speed clearly isn't everything but I think you picked terrible examples.

AOL might have been first but then they just seem to have quit. They didn't
keep up with the times. Their whole paradigm was terrible out of date. They
were in the ISP market but extremely slow and it killed them.

Lotus 1-2-3 was before Excel but Lotus took a long time to release new
versions while Office did not. You'll notice that MS isn't super quick with
releases now, but they do churn out new versions with some regularity.

Business doesn't have a finish line so companies have to start and stay fast.
This is why technical debt is a problem; sometimes you need technical debt to
get something out the door fast, but it will slow down future releases so you
need to get it under control.

~~~
dbg31415
In today's market, I don't see any customer being like, "Man, I wish this came
faster." Look at Blizzard... they focused on speed for their last expansion,
and they lost 3M subscribers. Look at all the automotive recalls this last
year. And really AOL... wasn't even first to market, Compuserve beat them but
like 10+ years.

There are many ways to get ahead. Bureaucracy sucks.

But just saying, "Speed man, speed... that's the good stuff..." It's only true
when it's paired with customer demand, high quality, and all the other things
users demand.

ICQ vs. AIM? I can't actually think of a single example of a product being
first to market and that making them better than the challengers. Getting to
market... no question, that's great. Blowing away what exists in the market...
that's what gets you customers. So inherently being first isn't advantageous
since you're opening the door to others taking your idea and improving on it.

I'll say again, build the best thing you know how to build... if you don't
build it great, people will notice. Nobody wants a quick and dirty solution
once they see the well-designed, delightful, secure, improved, etc. solution.

Facebook > MySpace

Instagram > Facebook

Reddit > Digg

Any modern software language... nobody is like, "Man, give me some ASP VB,
that came out before Rails or Node... it must be better." We evolve. Speed, it
may be a factor. But what you build has to survive past launch. Do your best
to give it the legs it needs... and maintain it as vigorously as you can. ROI
is in planning.

------
rcarrigan87
Surprising number of people on this thread are conflating first mover
advantage with moving fast.

First mover just means you are first to a new market. Hypothetically, there
could have been 10 years of product development behind your first mover
advantage.

Moving fast, as I see it, is not becoming that huge, slow organization (think
GE), that has so much bureaucracy baked-in nothing ever gets done.

Most decisions really don't require the level of debate they're given. The
author is pointing out that a lot of the decision making process is influenced
by shit that doesn't have anything to do with the actual decision.

~~~
ams6110
The reason big, old organizations tend to have a lot of bureaucracy and
process is that they created it in response to bad outcomes from lot of ill-
considered fast decisions.

~~~
bathMarm0t
I don't think it has to be entirely responsive to a specific poor choice. At
the company I worked at the bureaucracy increased hand in hand with the
complexity of the system (paired with the departure of the original systems
sages [who literally knew every specific of the aircraft on par with the
design engineers]). Single persons could no longer see the effect of their
decisions on the entirety of the system (and therefore needed to check with
others via protocols etc). Cascade that a couple times (smart, ambitious
people do not like filling out forms [in general]) and out pops a 20k employee
company where no one knows anything except how to fill out form 108DB-A.

Also it should be considered that if a small business makes a lot of ill-
considered, fast decisions, chances are they're no longer in business.

------
InclinedPlane
During the Vietnam war the US began to look into the unexpected
underperformance of its pilots in air-to-air combat. They weren't exactly
losing but they weren't doing nearly as well as they were expected to, and
there was a litany of mistakes being made again and again that were hurting
combat performance, all of which came to light in the "Ault Report". A lot of
research went into studying what was happening and why and ultimately a new
theory of aerial combat fundamentals came out of that research.

The main difference that was causing problems for American pilots was that the
planes they were fighting against were more maneuverable. It turns out that
greater maneuverability naturally led to a faster and more responsive cadence
in combat, leading to MiG pilots gaining the upper hand in encounters.

The two theories that came out of this study were Energy-Maneuverability
Theory and the idea of the "OODA loop". As it happens, OODA loop theory is
generally applicable in many situations outside of aerial combat.

OODA is an initialism standing for: Observe, Orient, Decide, Act. It is the
fundamental event processing loop for "doing stuff" in almost any situation.
The faster one's OODA loop the faster one can respond to changing situations,
which translates into huge practical advantages. And the amazing thing is that
this is somewhat independent of maneuverability.

OODA loop theory should be well understood by anyone in the tech industry.
It's a critical element for the competitive advantages of small startups over
big, entrenched competitors. And it's the reason why agile methodologies are
so often advantageous.

"Speed" is a crude substitute for understanding the value of feedback-based
iteration and the competitive advantage of tighter OODA loop cycles.

P.S. Raw speed is not a substitute for good design, thoughtful engineering, or
keeping technical debt under control. It is quite possible to speed yourself
right into a wall where you lose agility because of excessive technical debt.
Also consider the relative merits of building on good foundations, increasing
value exponentially over time versus constantly tearing down and rebuilding
disposable structures. Don't confuse busy work with craftsmanship, value
doesn't scale linearly with effort.

~~~
krallja
Book recommendation to go with the OODA loop idea: Tempo, by Venkatesh Rao

------
panic
This exact attitude is the reason why modern software is so bad. Dates are set
before anyone has any idea how long the software will actually take to design.
Then, when it turns out the dates were too aggressive, the design is
compromised so the software can be shipped faster.

That's not to say the article isn't right. Maybe speed really does win. But if
that's true, we might be stuck with terrible software forever.

------
yoklov
> "You know you're going fast enough if there's a low-level discomfort, people
> feeling stretched. But if you're going too fast, you'll see it on their
> faces, and that's important to spot too"

Most people can't tell the difference here, and failing to do that is deadly.
You can lose a lot of good engineers by forcing too much crunch, and that can
kill or significantly delay projects.

This happens not rarely in game development.

------
DrBazza
"A good plan violently executed now is better than a perfect plan next week."
General Patton. Because software development is so much like dropping as many
bombs onto a bunch of people as possible.

"I’ve long believed that speed is the ultimate weapon in business. All else
being equal, the fastest company in any market will win.". The irony that the
authors two previous employers were Google and Apple. Both of which are
massive companies that were (and are) famously never first to market with
anything.

"All things being equal": it's the company with the deepest pockets and the
best PR. Which is not equal.

------
logicallee
>All else being equal, the fastest company in any market will win.

All else being equal, the best-funded company will win. All else being equal,
the company with the catchiest name will win. All else being equal, the
company with the best product will win. All else being equal, the company with
the best-advertised product will win. All else being equal, the company with
the most stories being written about it will win. All else being equal, the
company with the better cafeteria will win. etc.

all true statements. don't mean much though...

------
Smushman
> All else being equal, the fastest company in any market will win.

Yea, no doubt. Don't even need an MBA to see that. If you have two equal
competitors, the first one to market has a useful head start.

I think this article is what I would call aggressive trolling; scoring points
by 'thinking different'. But essentially this is not more than standard
knowledge, repackaged as a hype laden pseudo-intellectual conversation meant
to score points.

~~~
pbreit
Except that you will find a lot of disagreement. Even here.

------
AnimalMuppet
See
[http://integratedleader.com/articles/40-70rule.pdf](http://integratedleader.com/articles/40-70rule.pdf)
for another take on this. (At least, I think it's the same thing - we want
certainty, and that causes us to take far too long to make decisions.)

------
sparkzilla
"Move fast and break things" is a way for immature and arrogant people to mask
the guilt they should feel for offloading their poor decisions and planning to
the end user.

~~~
rcarrigan87
Arrogance is spending twice the time perfecting a product that you come to
find nobody uses.

I'm not necessarily an evangelist of "Move fast and break things" but it's a
good mentality to speed up the feedback loop and avoid sinking a lot of time
into stuff people don't want (even if it's really well engineered).

~~~
sparkzilla
The best products I have release have been programmed by people who plan well,
take their time, and get it right first time.

------
somberi
"There is more to life than increasing its speed." \- Mahatma Gandhi

Also a commonly cited zen story:

Eager Student asked: “How long will it take me to be enlightened?”

“Ten years” said the master.

“What if I work twice as hard?”

“Twenty years” said the master.

~~~
vecter
These are a bunch of context-less quotes that are entirely irrelevant to the
article. The article didn't say that the purpose of life was to move fast. It
was saying that there are benefits to moving fast in the business world.

The zen story also sounds like complete hogwash. All else equal, if you work
harder, you will improve faster.

------
0xdeadbeefbabe
> There are decisions that deserve days of debate and analysis, but the vast
> majority aren’t worth more than 10 minutes.

Quick! I need a vast majority detector.

Setting a deadline for deciding something sounds good to me, but the above is
some kind of puzzle.

~~~
jfoutz
How much will it hurt if you do nothing? is a decent heuristic. Any time the
answer is "a lot" there's a big complicated change that needs to happen. If
there was an obvious or easy answer, it wouldn't have gotten to the "a lot"
level.

------
omouse
To the nay-sayers on speed as priority:

I'm currently on a two-week deployment cycle. It's not only annoying to wait
but it's also _dangerous_. There have been several incidents where the code
that broke something was committed a whole week or two weeks before! Worse
still is that we're deploying two systems at once and usually we're patching
the systems at the same time. So you have a perfect storm of bad things that
can happen with multiple causes. Faster means you see the problems sooner.

~~~
mschip
I see what you're saying, but maybe if you didn't go so fast you could have
had properly tested code that didn't break something in the first place. I'd
argue that not breaking it in the first place is better than speeding up to
find the break.

~~~
omouse
Yeah I see what you're saying as well and I agree with that. It's hard not to
break something when our release cycle depends on a QA person and on customers
to break things that we can't always test for (and we're actively discouraged
from writing unit tests and other automated tests).

------
mizzao
> There’s not always a stark tradeoff between something done fast and done
> well.

Yes, there is:
[https://en.wikipedia.org/wiki/Project_management_triangle](https://en.wikipedia.org/wiki/Project_management_triangle),
and to have both requires more money (resources).

This article also doesn't seem to have been written by an engineer. I'd love
to get a more technical perspective on how to move fast.

------
hamxiaoz
On a side note, the hero photo looks realistic (has the 'pop' feeling),
wondering how to produce this kind of photo?

~~~
mh-
it's a mixed lighting/flash photography technique

------
skybrian
The answer as usual is "it depends". At the very least it depends on the
consequences of missing a deadline and how painful "undo" is if you screw it
up. A software update is much easier than a hardware recall. Formal processes
are necessary when undo becomes painful enough.

------
pbreit
I was prepared to disagree but, you know what? He's right. Very few decisions
are irreversible or benefit from extended debate or analysis. Some keys are
that you have to be prepared to undo and not crap on the decision-maker.

------
maxxxxx
I hate it when people narrow things down to one factor. Yes, speed can be
helpful, but you still need to balance it with other factors like quality.
Speed for its own sake can kill you quickly.

In short, you need to know what you are doing and why.

------
itistoday2
I remember how many __years__ it took Apple to figure out how to do right-
click properly while their competitors were speeding along with that silly
second button.

Speed is important. Patience is important. Stepping back and smelling the
flowers is important. It's not about fast or slow. It's about right, and you
can't be right all the time if you're stuck in the habit of zooming along all
the time.

~~~
ams6110
I always heard that the one-button mouse was a Steve Jobs mandate. So users
didn't have to think about which button to click. Of course the NeXT had a
two-button mouse, so maybe not...

------
michaelochurch
Am I being asked to take seriously the company that produced this atrocity?
[https://www.youtube.com/watch?v=bMJIBxtDUHc](https://www.youtube.com/watch?v=bMJIBxtDUHc)

~~~
CPLX
Oh. Wow.

------
rglover
Wheeee!

[https://www.youtube.com/watch?v=m4UPvorv2qY](https://www.youtube.com/watch?v=m4UPvorv2qY)

