Agilism: Out, Googlism: In
When I started reading Steve Yegge’s latest article I was optimistic. The title sounded promising. The quote from Wikipedia was great. And the arguments against the Agilism religion were well articulated. The first couple of pages were really a great read.
Then, as I began to read Steve’s description of “the Google experience”, my enthusiasm started to fade. At first I thought I was just envy. After all, who can resist working with no deadlines, being flooded with rewards and incentives, and eating great (and free) food all day? Oh, and let’s not forget the fact that you get to choose the project and the team you want to work in on a daily basis. It’s heaven on earth!
But after reading on, I realized that the strange feeling I had was not envy. It was a déjà vu feeling. So, I went back to the top of the article and started reading it again.
Okay, I admit it: Google does sound like a great place to work in. I’ve never worked for Google, so I can’t know for sure, but I have no reason to doubt it. But Steve’s description had something else in it. It was almost religious. Or, as one of Steve’s readers accurately phrased it:
“When you hear people talk about working at Google its like listening to someone who just found Jesus.”
Yep. That was where my déjà vu feeling had came from! It was like reading Extreme Programming Explained all over again. A new religion is starting to emerge. And judging from the number of links to Steve’s article, the books, the seminars, and the endless consulting sessions, are just around the corner.
You see Steve, you could have gotten away with it if you hadn’t written such great arguments against Agile. Let’s see now. Here’s one of them:
“The consultants kept going with their road shows and glossy pamphlets. Initially, I’m sure they went after corporations; they were looking to sign flexible contracts that allowed them to deliver “whatever” in “2 weeks” on a recurring basis until the client went bankrupt. But I’m equally sure they couldn’t find many clients dumb enough to sign such a contract.”
That’s really hilarious, but more important, it is true. At least the part about no client being dumb enough to sign such a fuzzy contract. I wonder what Googlism has to say about that:
“Most of us in our industry are date-driven. There’s always a next milestone, always a deadline, always some date-driven goal to it.
The only exceptions I can think of to this rule are:
1) Open-source software projects.
2) Grad school projects.
3) Google.”
Working without deadlines! Isn’t that convenient? Maybe Google can afford it, but can you? For most companies this is as practical as sending all employees to a one-year paid vacation. Why? Because the same clients who will never sign a fuzzy Agile contract will also never sign a contract with no deadline.
And for the exact same reason almost no company can really have its developers changing teams with a one-day notice. When you run a software project you usually can’t afford waking up one day only to find out some of your developers are missing no matter how good your code is.
Now I’m in a difficult position. On the one hand, it all sounds great. Many of the things Steve talks about were even discussed in this humble blog. But let’s face it, the way Steve describes it you have only two choices. The first is to join one of the few companies in the world (if not the only one) that can afford creating developers’ heaven. The second is to go on fantasizing. So, should I add Googlism to the long list of promises in my previous post?
But maybe there’s a third option. Not an easy one, though…
Don’t take anything you read for granted, especially when it is spiced with religious passion. Adopt the good ideas, but drop the impractical ones. Think for yourself and try to come up with the optimal solution in the context you operate in. Remember that no article, book, or seminar in the world can have it all figured out for you. Not even this article.
***
PS. You should really read the comments to Steve’s article. There’s a lot of them, but trust me, many of them are very enlightening.
September 30th, 2006 at 4:28 pm
I think the high morale and concentration of genuine talent at Google is what makes it tick. After all, if I was able to work on my pet projects (which of course are web-oriented) I would put much more time and mind into them, then I do for my current employer, adding yet another layer of mud on top of my old CMS code that I should have rewriten a long time ago.
I’m not saying I do a very bad job, but I do the “fun” coding after hours — and ask yourself, if someone payed you to work 8 hrs a day on your pet projects, wouldn’t you be happy to work hard? I know I would :)
That said, I think Googlers don’t actually work without a release calendar, but rather without specific deadlines for when does the project monetize. And that also pays for itself because, and I think most programmers would readily agree, applications should be released not when the time runs out, but when they’re ready.
To make a long comment longer, applying GTD would be so much easier if I would have enjoyed every “next action” from the pile. Hell, I’d even be happy to help design a GDT application.
September 30th, 2006 at 7:45 pm
A successful software methodology (not new, others have suggested it):
(1) Hire really smart people
(2) Set some basic direction/goals
(3) Get the hell out of the way
In addition to the steps about, there’s another key: RETENTION. This is basically the “secret sauce” over at Google and a number of places. They’ve figured out that the above works, and everything else about how Google works revolves around RETENTION and ATTRACTION of talent. All the food, money, etc, is to make it attractive to the top performers to stick around.
How do you make developers want to work for you? Make them believe the things they hate most don’t exist in your environment. I haven’t worked at Google, and don’t have any inside knowledge, but I do know its a publically traded company, and at the end of they day they want to make a profit and make the shareholders happy. Do I believe they truly don’t have deadlines? No, I don’t. They don’t have deadlines they tell developers about, but I bet they have an idea of how long they’ll let a project go along before they kill it off. I also bet while it may be true that you can swap teams every other day if you want that it won’t serve you well when it comes to bonus time.
Bottom line, they’ve figured out the 3 steps about, and then built an internal economy that ensures:
(1) Bad projects die, and good projects complete
(2) Bad developers leave, and good ones never ever ever leave
I’d love for someone at Google to weigh in on this with internal insights. I can say the two things I’ve seen absolutely kill performance on teams is:
(1) Bad projects that just don’t get killed. A company that keeps beating its head against the wall just because they don’t “quit”. Stupid, insane, and bad business. Worst of all the good developers smell out these failures waiting to happen and get frustrated beyond all hell when the project keeps running like the Energizer Bunny.
(2) Mediocre or bad developers lingering along because a company is unwilling, unable, or just completely clueless about performance management. Nothing will drive a project straight to hell faster than some below average performers. Not only do they drag down the project but they drive the top folks out of the organization faster than anything. Sure, there are some people who “like” being the biggest fish in a very small pond, but most top performers like to be around other top performers.
Combine the above two and you have a recipe that ensures you’ll be looking for a silver bullet in any methodology anyone can come up with. Problem is the only thing that really works is to solve the real problems. This leads me to a one-word silver bullet software methodology:
THINK
September 30th, 2006 at 10:54 pm
Thanks for both comments.
Generally, I agree with what you say. But there is one point, however, that must be clarified. Well, actually two:
1. Hiring excelent people is not a guarentee for good products (as BradM wrote). But more important :
2. If by any chance not all your developers are “excellent” (which is generally the case) you can still do something about it: work with them — mentor them — to build their skills and experience. In the long run this may proove to be even more cost effective than hiring only top developers. Nurture professionalism in-house.
See: http://blog.qualityaspect.com/2006/04/10/mastering-context-sensitive-domains/
Lidor
October 1st, 2006 at 3:27 am
If you read “no deadlines” and you think about it’s fundamental meaning you come to this:
“no pressure, no obligations, only fun”
And so it becomes apparent that there are things untold about the “no deadlines” approach. PROJECTS have no deadlines but they have DELIVERABLES and REQUIREMENTS.
There are “no deadlines” on projects but does this mean developers can do whatever they want? Ofcourse not, developers are evaluated, their performance is screened. So although they do not work towards deadlines they do have to deliver enough stuff so that their managers are happy about them.
So “no deadlines” mean “we’re going to put this strange kind of pressure on you that you’ve not experienced before” which could very well be comparable to the feeling you get from joining a new religion. At first it feels strange but everyone around you is having fun. But at that time you can’t understand the depths of what you’re involved in.
October 1st, 2006 at 4:32 am
I agree completely with Lidor, and didn’t mean to imply the only way to have excellent developers is to hire them. In fact its part of the point - too many companies are completely clueless about peformance management. I’ve been places where it means you just axe the botton X% and I’ve also been places where it means you do nothing and just “work around” the bottom X%. Neither approach works as well as actually thinking about performance and both hiring carefully to fill gaps, but also mentoring and guiding…
October 1st, 2006 at 4:37 am
Right after I read the above I re-read my post. In fact there’s another point I missed - bad projects (just like poor performers) don’t have to go away, but they do have to at least change into good projects. Again, the key is realizing when what you’re doing isn’t working and then doing something about it.
It sound really obvious, but I’ve encountered so many organizations that don’t face and instead just beat their head against the wall.
October 1st, 2006 at 6:06 pm
Google doesn’t have customers (they have advertisers and users, but not customers with chequebooks asking for software), so there’s noone they need to force into signing a contract without a deadline.
That probably works great for some companies, but some products are built for a specific customer for a specific reason, and thus need a different management style.
Praise Google!
October 3rd, 2006 at 7:05 am
Once again, Lidor, you’ve expressed what I’m thinking over at pliantalliance.org better than I ever could. That last paragraph in your post is pretty much the definition of pliant software development I’ve come up with to counter Agilism, and any other -ism that purports to have all the medicine we need for our software development ailments. Thanks for promoting the novel idea of thinking for ourselves and working within the constraints and context we find ourselves in.
October 3rd, 2006 at 7:08 am
[…] Oh well - check this post out. […]
October 3rd, 2006 at 7:13 pm
[…] Agilism: Out, Googlism: In […]
October 28th, 2006 at 8:13 pm
[…] Anyway, the recent online kerfuffle hit its climax with Steve Yegge’s “Good Agile, Bad Agile.” However, I don’t think just any software outfit can operate the way he describes Google operating, which he holds up as the alternative to “Bad Agile”. For one thing, not just any software outfit is Google. It seems like a lot of people got worried about an impending “Googlism craze” replacing the Agile craze. But the lesson I took from Yegge was, be more concerned with being agile than with being Agile (note capitalization). […]
January 1st, 2007 at 8:12 am
hi