Heroku: Why Instant Deployment Matters (YC W08)

<i>Once every hundred years media changes!</i><p>I wish people would stop conjuring up mathematical models to add drama to their observations.<p>Firstly, mathematics makes for poor theater. Secondly, the silly models distract from otherwise sensible observations: media changes and development gets faster.<p>But, in the end, the only sensible sweeping generalization may be <i>past performance does not guarantee future results</i>.

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.<p>Here's what bothered me about this post:<p>- Scrum fanboyism. It was unexpected and threw me off track while I was reading. I felt it negatively detracted from your point.<p>- 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.<p>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.

Are these numbers based on speculation?<p>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.

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.<p>On the other hand, the main argument - that the percentage of effort occupied by deployment has grown - may not need that figure.

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.

Comment I left on the post:<p>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.)<p>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.<p>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.<p>That is the ideal I'd like to reach.<p>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.

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.<p>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.

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

I get the sense that your numbers are based on speculation rather than hard data.<p>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.<p>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.<p>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.<p>Cool idea for a service though. But maybe you're painting the picture a little more dire than it needs to be.

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.