

Heroku: Why Instant Deployment Matters (YC W08) - jnl
http://blog.heroku.com/archives/2009/2/23/why_instant_deployment_matters/

======
falsestprophet
_Once every hundred years media changes!_

I wish people would stop conjuring up mathematical models to add drama to
their observations.

Firstly, mathematics makes for poor theater. Secondly, the silly models
distract from otherwise sensible observations: media changes and development
gets faster.

But, in the end, the only sensible sweeping generalization may be _past
performance does not guarantee future results_.

------
teej
I get your point: the deployment-to-development ratio has increased as we've
streamlined development processes faster than deployment processes. I
understand the underlying theme, Heroku is going to kickass in deployment.
More power to you.

Here's what bothered me about this post:

\- Scrum fanboyism. It was unexpected and threw me off track while I was
reading. I felt it negatively detracted from your point.

\- Capistrano bashing. You certianly gave Cap it's due, but calling it an
"incremental improvement" compared to what you've got in store takes balls.
We'll see how that pays off.

I know this is just a preface to some (hopefully) technical articles about
your work, but on it's own, it's just fuzzy math and hype. Here's to some meat
in the next one.

~~~
jamesheroku
Awesome comment. Wow, "scrum fanboyism" is definitely not what I was going for
there - just trying to poke fun at how these teams have changed over the
years.

Yes, the technical details are on the way - we're excited to share them.

------
volida
Are these numbers based on speculation?

Since when serious applications are written in 1 week in 2008? You could write
1-week applications since the dawn of computing. Haven't you heard? BASIC was
written by B. Gates and P. Allen in 8 weeks.

------
gruseom
Has software development really gotten 160x faster in the last 10-15 years?
It's a moving target, of course, since people keep trying more ambitious
things as tools get more powerful. But that number doesn't feel right to me.

On the other hand, the main argument - that the percentage of effort occupied
by deployment has grown - may not need that figure.

~~~
Hexstream
Considering there are things you can do with web apps now that you couldn't do
at all in 1996, I'd say for some use cases web development is now "infinitely"
faster.

~~~
gruseom
Sure you could. You could have built the web and everything you needed and
then written your app :)

"Development is faster" presumably means "relative to what people are trying
to do". That's the sense in which the OP uses it, because he's talking about
development going faster per project. The concept is problematic since what
projects consist of has changed as much as everything else has.

------
jseifer
The figure that are stated in the article are quite obviously made up but
conceivably close to real life scenarios. I think the author is way off on the
last example, though: "It then takes just one person a few days to provision
new resources from IT or a fast-moving hosting company, install the default
web stack, and do the initial deploy." I can see that for an IT department but
not for a fast-moving hosting company. With all of the deployment tools
available, most of the deployments I've done have ranged from a few minutes
(RailsMachine) to a few hours (barebones install). All that aside, though,
instant deployment would be pretty darn cool.

------
melvinram
Comment I left on the post:

As a potential customer, instant deployment is not what appeals to me. If I
knew that 1 day after my code was done, my app would be working just
perfectly, I'd be a happy camper. Instant deployment = cool but not mission
critical... at least not for me. (Now, if deployment took 2 weeks, I'd be
pissed.)

What appeals to me about Heroku is exactly what I like about my MacBook Pro:
It just glides. I don't have to think about it. Things just work (at least in
theory.) It's not the time, but the thinking about deployment that I'd like to
remove.

I just click the magic deploy button (command) and tada, "It's a live." And if
I hit the jackpot and land a massive client or show up on TechCrunch, things
will just keep on gliding smoothly. And hopefully, I'll make more money and
serve more clients.

That is the ideal I'd like to reach.

Now instant deployment might be something I fall in love with (like git) but
I'm not there yet. I just want things to "just work" for now.

~~~
jamesheroku
Ah, bingo. Yes, "it just works" and "it glides" are exactly what we're going
for. Our version of the magic deploy button is "git push". We've got some
great detailed posts coming up about this.

The thing that we've discovered is that instant and "it just works" are
tightly related. If something takes minutes or hours to do (even if
automated), it's likely that there are many steps involved - each of which is
a potential point of failure.

~~~
ryanmahoski
Your last sentence rings especially true. Each step is a potential point of
failure. I tried to set up cap and passenger one day but got stuck on a couple
of steps. Sure I could have plowed through and gotten it to work eventually,
maybe switched to a different computer or whatever but time is precious. The
word "easy" is thrown around too casually in tech circles. Today I've got
three domains running on herokugarden and it still shocks me how short the
procedure is. Thanks.

------
okeumeni
The historic argument you guys are trying to push trough to enhance your pitch
is shadowing the purpose of your heroku itself because of its controversial
nature.

I will advise you remove the whole history thing from your argument and take a
different approach of selling your tool which I think has good potential.

~~~
colins_pride
I agree. It's enough to say that development has gotten much faster, but
deployment is still a slow pain in the neck, and you are the guys who are
going to change deployment. Most of the time the smooth, concise story sells
best, in my experience.

------
dilanj
A valid point undermined by the extravagant attempt to prove it.

~~~
akido
I think the numbers/graph are necessary. Of course they are made-up, but the
point is the trend over time. I find this argument quite compelling, and I
wouldn't have found it interesting had it just been a qualitative description
of these trends.

------
jasonkester
I get the sense that your numbers are based on speculation rather than hard
data.

I have several examples of sub 1 week development time to first release from
projects we've done in the last few years. But then the initial deploy for
those projects, on average, took about 20 minutes of one person's time.

Iterative development often goes hand-in-hand with iterative deployment.
Somewhere during week 3, we'd spend an hour moving onto an automated build and
deploy system, and from there on out it would be push-button.

Once, and only once, the site got big enough to need its own dedicated box at
a colo, so that added an extra couple days building a server, driving it to
the facility and moving the site. But by then we were 3 months into
development, so the effort was nowhere near 25% of our total spent man hours.

Cool idea for a service though. But maybe you're painting the picture a little
more dire than it needs to be.

------
simonb
One thing his historical comparison completely neglects is there was a time
when people actually cared about performance (or rather they were so
constrained by it they were forced to care). On the other hand most of these
one-week wonders suffer from "we'll just throw more HW at it" syndrome.

