Good agile vs Bad agile | Hacker News Reader

Good agile vs Bad agile

steve-yegge.blogspot.com

50 pointsjoubee21 comments

I think this post is worthwhile because Steve works for one of the best software development companies around and because he's an excellent programmer with a lot of experience.

He obviously knows what he's talking about.

I think what's missing (perhaps because he's not the best person to describe it) is what a company on the wrong path can do to set things right.

Google has obviously made a very conscious effort to keep their successful model as they've grown, bit many companies (especially those not started by techies) have made bad decisions.

How can an IT department -- assuming the department itself gets it -- make things better?

Unfortunately, lame parties are about the extent of the power most IT departments (or development team managers) have. They can't shift the entire culture of the company or start handing out astronomical rewards.

There has to be a middle ground, and it's this middle ground that's so elusive.

I would be interested in hearing how anyone has driven or been part of a lasting, positive change within the confines of a larger organization.

Oldie but goodie. One comment:

the kinds of programmers who buy extended warranties and self-help books and believe their bosses genuinely care about them as people, the kinds of programmers who attend conferences to make friends

One of these things is not like the others. I have made many, many friends at programming conferences. I am not sure why you wouldn't expect this to happen.

I agree with you, especially with regard to open source related conferences (I've made great friends at PyCon); but perhaps there's a difference at the more old-fashioned corporate conferences?

"I'm not here to make friends." http://www.youtube.com/watch?v=w536Alnon24

Now I remember why I am ashamed to be American.

Yeah, I didn't understand that either. Maybe it's because I'm a weirdo, but the main reason I go to tech conferences is to make friends, who inevitably turn into business partners and clients.

Great post, especially the bit about life at Google:

- developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.

- Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.

It's brilliant management I think: Hire talented engineers, give them extreme freedom, and choreograph the dance with clever incentives...

The article was written 3 years ago, so I'd be very curious to hear how much of that still is accurate today.

Yes, nowadays, Google "allocates" (the actual word that they use) new employees to projects.

Steve Yegge, if you are reading this: please write a book. I'd buy it!

I'd be overjoyed if he just started blogging again.

I never made it through all of the "Programmer's View of the Universe" series, but I loved reading nearly all of his other stuff.

I'm of the opinion that Agile(Big A) is very useful for creating a system between companies. When something is an agreement between companies you need some agreed and consistent method of working out what happens when and enforcing that afterwards. Agile is much better in these circumstances than waterfall.

Comparatively, in a startup or internal development project in a software company there is much more of an ability to not deliver a particular feature or spend more hours on it.

A startup is likely to find Agile far too slow; whereas, corporates are scared by how fast and fluid it is.

If anyone cares, I wrote an article for InfoQ around this time which gathered some of the better commentary: http://www.infoq.com/news/2006/12/future-of-agile (buyer beware: I am (or was, at least) biased in favor of agile methods).

these are the kind of discussions i find worthwhile: an honest look at how something works well and how something fails. too often i see blog posts pitting A against B, or simply claiming A sucks.

(i guess A v B is a good/bad look at a higher level concept C...)

Yes, but it's amazing how often people don't bother to move on to C. They'd rather see the A vs. B slugfest and contribute to it!

What he's describing as "good agile" deserves a different name. I'd call it "fluid" because that seems like a really close metaphor.

I wish even agile had a different name, one that isn't so tempting for people to use incorrectly, with no clue that it means something other than "able to change direction quickly". I've heard (very non-technical) people cheerfully volunteer to clients and developers that the project they're involved with is "agile", but they just mean "we have no real plan, anything can change at any time" - they have no concept that there's an actual methodology being implied by what they're saying.

I think using a term like "fluid" would have similar results - "we're using a fluid methodology so our project will be able to flow around any obstacle/mould itself to any scenario".

On the other hand these ideas spread so well because it seems like they're easy to understand...the first thing you think of when you hear something like Rational Unified Process is men in white coats with pocket protectors.

All I could gather from the post is - "great incentives attract great talent produces great software".

Classic Line: "what metadata is allowed on index cards"

I vehemently disagreed with this post when it was originally written, but then at the time I was just being introduced to Scrum. I've since come to understand his point, and oddly enough, the part at the end where he talks about project management via queue theory and index cards is precisely what my startup (http://agilezen.com/) is based on. :)

All I can say is that was a fantastic post and thanks for sharing.

Reply on news.ycombinator.com