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

By: On Prioritizing Feature Development | idealfusion.com

On Prioritizing Feature Development | idealfusion.com — Thu, 16 Oct 2008 07:28:30 +0000

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

By: On Prioritizing Feature Development | idealfusion.com

On Prioritizing Feature Development | idealfusion.com — Thu, 16 Oct 2008 07:28:29 +0000

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

By: NerdPower

NerdPower — Tue, 12 Feb 2008 01:49:43 +0000

How is this in any way shape or form in the Agile domain? At the most this would be a good customer response example to cite.

Boy.. you must be new here..

By: jack

jack — Thu, 17 Jan 2008 20:34:13 +0000

Hardly novel. I see this sort of “live updating” all the time on littlegreenfootballs.com which is written in Java IIRC.

By: Mike

Mike — Thu, 17 Jan 2008 20:30:39 +0000

In response to some comments here, I think it’s amazing because PG responded to a user request that required some work (not just a lip service email) in a manner of hours. Think of the requests, that make sense, that you see on the front page of reddit. They never seem to be acted upon, and those guys are not simultaneously running a venture fund with ~12 young, inexperienced entrepreneurs.

By: admin

admin — Thu, 17 Jan 2008 15:17:57 +0000

Good point Bob, bank was just the first impersonal, big IT producer I thought of. And yes, it’s all about his attitude – Lisp is just one of many technology choices that have been pointed out that would let someone make that same responsive change.

By: Bob

Bob — Thu, 17 Jan 2008 15:10:14 +0000

Kudos to pg for being responsive, but that’s a commendable attitude he has to his user base not the result of a technology choice.

Also bear in mind that he’s running a discussion board not a banking website – if my bank made realtime changes to application code, relying on me to verify the change I’d probably switch my account

By: admin

admin — Thu, 17 Jan 2008 14:46:38 +0000

I thought this might be under-appreciated because most of the people who would read it are programmers. Think of it from the POV of the user. The point wasn’t that he used Lisp or Arc to do it – and it’s only a little about the technical achievement. It’s a combination of manageable, flexible code, good technology decisions, paying attention to your community, and successfully incorporating feedback.

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.

By: vasudeva

vasudeva — Thu, 17 Jan 2008 13:19:06 +0000

I’ve been reading about Arc, and it looks pretty interesting, but I’m not sure I get why this is such a remarkable concept. He modified the comments page to include a link to the relevant topic, right? I do that all the time with the site I just typed into this comment’s header. That site is PHP/MySQL. It usually takes me about 5 minutes — edit the template, save, and all future page generations are cached using the new code. Maybe longer if I need to work out some wonky SQL call.

Maybe I’m missing something?

By: NotoriousBRK

NotoriousBRK — Thu, 17 Jan 2008 13:16:55 +0000

OK, I don’t get it. Why is this so amazing?

I’m not the uber-Hacker PG is, but I’ve written my fair share of code. Many years back I was developing a ticketing and provisioning system in perl for an ISP I was working with, and did pretty much the same thing almost every day.

I had the main/live site, and a development site, which was just a copy of the main script with some debugging stuff in it. All day long people would come up with features/suggestions (or find bugs) and I would fix/add stuff pretty much in-line.

I think this is easy to do when:
1) The site serves a relatively small audience and could suffer a little bit of a hiccup

2) You have 1 or 2 developers working on the code, and it’s code that they understand (or wrote) completely

3) Your product is SaaS/web-based, so users need to do little more than hit “Reload” to get the latest version of your code.

#1 and #2 are important because the need to do rigorous QA is reduced. On a much larger and more complex project with many developers, features are often added just as quickly, but the release cycle is managed such that you as the end user might not see a new feature until 2 weeks after it was completed.