Live data from Hacker News

Heroku: Why Instant Deployment Matters (YC W08)

blog.heroku.com

11–18 of 18 posts

Re: Heroku: Why Instant Deployment Matters (YC W08)

#11

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 gli…

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.

Re: Heroku: Why Instant Deployment Matters (YC W08)

#13
post #7

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.

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.

Re: Heroku: Why Instant Deployment Matters (YC W08)

#14
post #12

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

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.

Re: Heroku: Why Instant Deployment Matters (YC W08)

#15
post #3

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.

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.

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.

Re: Heroku: Why Instant Deployment Matters (YC W08)

#16
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.

Re: Heroku: Why Instant Deployment Matters (YC W08)

#17
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.

Re: Heroku: Why Instant Deployment Matters (YC W08)

#18

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 gli…

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 potent…

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.
Post reply on HN