People, Process

{

Steve Yegge has a post about the agile software development process. Gifted in wit and sarcasm, Yegge doesn't spare many punches in basically saying that "Agile" as is known as a process is basically about marketing and making money for consultants. He contrasts this with a lower cased "agile" which is what he believes Google (his employer) practices and others should.

A lot of comments seem to be coming back - resistance to Yegge's comments over at The Mindset because (and I agree with this) some of the things that are true for Google (working without deadlines) just can't be true for the rest of us. The Mindset also doesn't believe that the glossy, non-substantive Agile flies with most businesses. I'm not as optimistic as The Mindset since I have seen many an organization fleeced, but I do agree that most people aren't fools. Especially developers, the majority of which I've worked with are big skeptics.

Raganwald has the most interesting response I've seen so far: that it all comes down to people over process and a good team will succeed despite methodological strategy. Interesting because especially when it comes to Google, it seems like they take the cream of the crop so it would follow that they can be so lax with all the rock stars they have working there. Raganwald seems to fit into Spolsky's camp (maybe it was Raganwald's camp to begin with) where the equation is: Good programmers + working conditions == Great Software

Dare Obasanjo is pretty straight forward with how he sees Google:
"'smart people dicking around' type projects" versus "shipping code."
It doesn't get more plain than that now, does it?

Quite interesting especially since it wasn't long ago that I listened to Jutta Eckstein talking about Agility on Software Engineering Radio. The first thing out of her mouth was:
"People over process."

I think there's a lot of frustration in the marketing and money making of Agile but the finer details seem to have a lot of things that are great tactics in software development. "People over process" is a great way for the Agile methodology to begin itself since it allows for the Raganwald/Spolsky perspective but many of the communication things are good as well. What Yegge points out as "agile" in the sense of big rewards and incentives seem to have to do with compensation, not necessarily development methodology. Pair programming, as far as I know isn't a part of Agile but this is something I've never really seen as a full time approach. One thing I've been struggling with in my current project is the weight given to doing frequent releases in Agile. Because we started from scratch it doesn't make much sense and in this case we are departing from conventional Agile. However as the framework for the software begins to take form I'll push the team for more frequent builds that the client can look at. For now, scaffolding and putting things together for others takes far too much time and all the client would see is unfinished stuff that we are well aware is unfinished. Doing "SCRUM" meetings is another departure for us - we meet when necessary but there's enough on various plates to make meeting and percentages too much overhead.

In the end I find myself seeing truth in each person's perspective: Yegge is right about some of the dogma (whether it was intended or not is another question) some apply to Agile programming. The Mindset is right that those of us who don't work at Google don't have the luxury of working without a deadline. Raganwald is absolutely right on the importance of hiring. I did two interviews this week and that was... interesting. People, especially the caliber of whom work at Google, just aren't a reality for where I work. I include myself in that category since I'm not certain I'd fare too well in their hiring process.

}