I disagree. It sounds like you work for a company who has their build process worked out really well, so fast changes are less impressive to you, but have you considered that maybe your company is not the average? I think it would be fair to say that most development shops are NOT that responsive to user changes because they don't have either the language features pg used, or a well-thought-out build process like your company.

If the article author works at one of those "average" shops, I think he has every reason to consider his experience on news.yc as a breath of fresh air and tell other people about it as an example.

Additionally, I think part of what impressed the author so much was that pg took the time to handle the request immediately. This isn't a site anyone pays to use, there's no revenue incentive, and the request was not the early stage of a riot, but they took care of it as though it was as important as a paying customer relationship, and that's not a response you expect from most web services. In fact, I think that may be what impressed the author more than just the speed of the fix.

I should have known the magic here would be completely missed by much of the Hacker News audience - same thing happened with the comments on my blog. The whole point was that it WASN'T about the technology - it was that he's so in touch with his audience that within 4 hours of it coming to his attention, he was able to do two iterations, get feedback on both, and fix a bug. It took 4 hours because we were communicating asynchronously on a message board, but I'm pretty sure he could have done it live if I had him on the phone. Simply put, I was more impressed that he gave a crap than that he could push a code change.

I am at one of those "average" shops, as are most people (by definition, although maybe not in the HN community). I know this stuff is possible but we can't do it here, and neither can most sites.

To put it in perspective, if you found a bug in your bank's website and told them about it, how long would it take for them to fix it? Even worse, what if you suggested a way to make the site work better? Would anyone with decision making power ever even see the suggestion? Just try telling someone WHO'S NOT A GEEK this story and see what they say. I wrote the article because when I told my wife what happened, her jaw hit the floor.

"To put it in perspective, if you found a bug in your bank's website and told them about it, how long would it take for them to fix it?"

To put it in perspective, this is a very simple, small application with a relative handful of users that ... publishes links.

Would it be impossible for larger, more "serious" websites to try harder?

Not to mention that such serious websites will have more resources available.

Not to mention that such serious websites have more at stake and most likely have a team of developers that learned the hard way not to change product code on the fly.

Fair enough. I guess we do have a system for making rapid changes in place, and I'm just used to be able to do that sort of thing regardless of the language.

No kidding. I would love for my company to have a process for deployment that's as smooth as the one you're describing.

We are consultants here in Bangalore and we have routinely done this on a Python/Django social networking web app and a Ruby on Rails web app. code-test-svn commit - svn export , pretty much. With a lot of java experience, I can say that it is more elaborate and laborious in Java than python or ruby. The erlang movie (http://video.google.com/videoplay?docid=-5830318882717959520) shows off the same, for erlang.

It's also true that I assume these things are just like that partly because I founded a company that handles build and deployment... http://www.electric-cloud.com

The article is a little overenthusiastic, but it did strike me while this was happening that something new was going on. I'm very familiar with the model in which changes to a web app get pushed out quickly. But this felt different because (a) it was the result of a conversation with the users while they were using the site, and (b) I typed the changes into the repl of the running server, iterating through design options (and debugging) on the fly. These changes are still not released; if the server crashed and restarted, they'd disappear. (I saved them to a file on my development machine, and the server crashes rarely enough that I'll almost certainly release the latest version before that happens.)

It's probably the REPL part that's the most interesting from a coder perspective. For most languages you'd at least have to reload parts of the application to get this to happen.

Of course it was overenthusiastic - that was so people would read it! I used three key attention getters just in the title so more people would take a look:

1) "capital A" Agile (even though it wasn't really about that) 2) reference Paul Graham (always a lightning rod :) 3) Ask a challenge question "Are you this [positive adjective]?"

Wow, people really don't like attention getting headlines.