4 ms·

Are You This Agile? Paul Graham Changes Hacker News While You Wait

22 points by pchristensen 19y ago

neilk 19y ago
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.
- bayareaguy 19y ago
  agile [aj-uhl, -ahyl] Pronunciation Key adjective 1. quick and well-coordinated in movement; lithe: an agile leap. 2. active; lively: an agile person. 3. marked by an ability to think quickly; mentally acute or aware: She's 95 and still very agile.
  - willarson 19y ago
    Although refutation by dictionary is a valued technique, I think its invalidated here by the capital A in Agile.
    - bayareaguy 19y ago
      The word Agile appears exactly once in the article: the title (where every word is capitalized). Yes, it's possible he's referring to Agile Programming but that's a stretch given all the other facts here.
- pchristensen 19y ago
  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?
  - pg 19y ago
    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.
  - neilk 19y ago
    I said that the article title was wrong, not that pg was wrong, or that Agile is even the best way to do things. The equation of "we iterated faster == we're more Agile" is what I thought was retarded.
    - pchristensen 19y ago
      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.
      - almost 19y ago
        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.
        pchristensen 19y ago
        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.
  - deleted 19y ago
jbert 19y ago
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?
- gibsonf1 19y ago
  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 http://www.cliki.net/asdf
  - jbert 19y ago
    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
- shiro 19y ago
  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.
bjelkeman 19y ago
Well if Paul can do this, then maybe he can put a password change or retrieval feature in. /sigh
- hhm 19y ago
  The feature is already there... "reset password"
  - LogicHoleFlaw 19y ago
    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.
jgrahamc 19y ago
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.
- eVizitei 19y ago
  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.
  - jgrahamc 19y ago
    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.
    - eVizitei 19y ago
      No kidding. I would love for my company to have a process for deployment that's as smooth as the one you're describing.
edw519 19y ago
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.
marcus 19y ago
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.

22 points by pchristensen 19y ago

neilk 19y ago

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.

bayareaguy 19y ago
agile [aj-uhl, -ahyl] Pronunciation Key adjective 1. quick and well-coordinated in movement; lithe: an agile leap. 2. active; lively: an agile person. 3. marked by an ability to think quickly; mentally acute or aware: She's 95 and still very agile.
- willarson 19y ago
  Although refutation by dictionary is a valued technique, I think its invalidated here by the capital A in Agile.
  - bayareaguy 19y ago
    The word Agile appears exactly once in the article: the title (where every word is capitalized). Yes, it's possible he's referring to Agile Programming but that's a stretch given all the other facts here.
pchristensen 19y ago
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?
- pg 19y ago
  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.
- neilk 19y ago
  I said that the article title was wrong, not that pg was wrong, or that Agile is even the best way to do things. The equation of "we iterated faster == we're more Agile" is what I thought was retarded.
  - pchristensen 19y ago
    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.
    - almost 19y ago
      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.
      - pchristensen 19y ago
        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.
- deleted 19y ago

jbert 19y ago

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?

gibsonf1 19y ago
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 http://www.cliki.net/asdf
- jbert 19y ago
  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
shiro 19y ago
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.

bjelkeman 19y ago

Well if Paul can do this, then maybe he can put a password change or retrieval feature in. /sigh

hhm 19y ago
The feature is already there... "reset password"
- LogicHoleFlaw 19y ago
  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.

jgrahamc 19y ago

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.

eVizitei 19y ago
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.
- jgrahamc 19y ago
  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.
  - eVizitei 19y ago
    No kidding. I would love for my company to have a process for deployment that's as smooth as the one you're describing.

edw519 19y ago

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.

marcus 19y ago

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.