Stupid article. Sorry. The change that PG made is tiny. So it was surely an easy change and so his responding in under 7 hours is hardly something to blog about.
Right now I'm working for a very large European web site that's entirely written in Java. We make changes all the time (e.g. we probably make at least 3 code changes to the web site per day). Doesn't need any magic PG pixie dust sprinkled on the engineers to make this happen. What we do is run all our web server/app server combinations inside Solaris zones. When we make a change we tell the production system to shutdown each zone when it's ready (finished with current requests) and load the new one.
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.
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.
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]?"
Let's not miss the critical "take away" message of this article...
Often, it's NOT the capabilities of the app that are the most important thing, it's the ABILITY TO CHANGE those capabilities quickly that matters most.
I've seen this over and over and over again in businesses. When the app (often packaged) is missing a certain feature or capability, the organization will always find a way around it: a satellite app, an excel spreadsheet, pencil and paper, even hiring a few extra clerks. But what really drives them nuts is when the business has a new critical requirement and the software can't be changed in time to meet it.
The examples are endless: we're running a special sale, we have a new temporary warehouse, the accountants insist on special security for certain classes of workers, Joe just found out that <abc> has happened in Duluth - if we knew <def> by 3:00, we could do <ghi>.
I know many business people that will only buy packaged software with source code. They will not pay maintenance, and use the money instead to hire their own programmers. It's THAT IMPORTANT that the software can "turn on a dime" to satisfy rapidly changing business requirements.
Bravo, pg, for doing something (however apparently minor) to bring this issue front and center where it belongs.
Doing this on a web application isn't really that impressive and could have been done in almost any language.
The awesome thing is that this could have worked with an installed desktop software, without downloading new binaries and installing them, simply having the application download a tiny text file with the source code change to input into the REPL.
No recompiling, no pushing huge binaries, no hassle.
I had to implement a big cumbersome system to enable automatic incremental live updates on our client software, so users will always use the latest version. Using Lisp just makes it a breeze.
The article title is wrong; Agile-ness is not measured in the speed of an individual change from code to customer. Any production-server-fuxoring-code-cowboy can do a change faster.
The Agile way would slow down particular changes, with practices like testing. The theory is that you take a little more time for every change in order to maintain optimum speed over the long term.
Who says he didn't test the changes before he published them? In four hours of asynchronous communication, he did two design iterations, got feedback on both, and fixed a bug that someone found. And this was unplanned, in response to unsolicited feedback. What else should he have done to slow it down more?
Honest confession? The original title was "Can Your Website Do This?" but I changed it to Agile so more people would read it. Notice that I never mentioned Agile in the entire article and it had nothing to do with it. Sneaky, I admit, but right now I'm trying to get more people to read my writing.
Have you tried actually writing interesting and engaging pieces? I know it's a little harder, but it's less of an arseholeish thing to do than manipulating social news sites.
Well, I spent about an hour writing the piece. I proofread it. I linked to the relevant parts of the dialog to make it easier to skim. I summarized for those who didn't want to follow links. I inserted screen shots for context. I linked to the other sites where it was being discussed. I added updates and clarifications in response to comments made on 3 different sites (mine, here, and reddit) to help the conversation. And it is related to Agile principles. Can I get some credit for doing those things?
I do apologize if you clicked on it looking for something about Agile and then found it uninteresting and unengaging.
I didn't test the changes before I published them. I basically did development on the running server. In fact for about 30 seconds the comments page was broken due to a bug.
I like the idea of a REPL into my web app (may add one actually - different language, but that's not the issue).
But can a production-lisper tell me what is best practice regarding versioning and saving to files?
I'm assuming that modifications via the REPL are affecting the running image only. Can the running image save back out as source? (I'm assuming not, surely comments etc aren't preserved?)
Is it down to the admin to replay all changes they make to the REPL to the app source?
When I ran CL server (it was in-house service, but heavily accessed 24/7 and I couldn't stop it to update frequently), I used a few ways, depending on how imminent the problem was.
The normal routine was to change the source, test it, then from server REPL I just reload it. If the problem was more serious that I had to fix it ASAP, I sent the definitions directly from the editing source to the REPL (in Emacs it's just a couple of keystrokes).
It was only when the situation was extremely serious (e.g some bug stopped large part of the production pipeline) that I typed expressions directly into REPL and afterwards I put the fix into the source. It was pretty rare, though.
Our process is to test code first locally, push it with Git to the server (on the cloud) then type: (sf-load) on the server REPL - done (less than a minute). The (sf-load) function loads the asdf file which recompiles any code necessary with the changes, such as dependent macros, etc, automatically. The server continues to run through the process - unnoticed by the user except for the sudden new features :) . http://www.cliki.net/asdf
Thanks to you and shiro for the replies. It sounds as though the REPL is more useful for inspection than modification - which makes sense. Graceful addition of new functionality is useful, but provided by other frameworks.
/goes off to think about how best to provide an inspection-based REPL to his web app
I got bitten by that one. I'd forgotten my password, but couldn't retrieve it because "logicholeflaw" wasn't a valid account. But I couldn't recreate it because "logicholeflaw" was already in use!
After a while I figured out that capitalization counts. But still, it was a bit confusing.
Right now I'm working for a very large European web site that's entirely written in Java. We make changes all the time (e.g. we probably make at least 3 code changes to the web site per day). Doesn't need any magic PG pixie dust sprinkled on the engineers to make this happen. What we do is run all our web server/app server combinations inside Solaris zones. When we make a change we tell the production system to shutdown each zone when it's ready (finished with current requests) and load the new one.