

Are You This Agile? Paul Graham Changes Hacker News While You Wait - pchristensen
http://www.pchristensen.com/blog/articles/are-you-this-agile-paul-graham-changes-hacker-news-while-you-wait/

======
jgrahamc
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
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.

~~~
pchristensen
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.

~~~
yawn
"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.

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

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

~~~
brk
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.

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

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

~~~
pchristensen
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?

~~~
neilk
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
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
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
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.

------
jbert
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
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>

~~~
jbert
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

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

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

~~~
hhm
The feature is already there... "reset password"

~~~
LogicHoleFlaw
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.

