Coding Horror

Steve Yegge's scathing criticism of agile methodologies takes a page from Joel Spolsky's book. It's not merely an indictment of Agile, it's also a celebration of how his company does business. Just substitute "Google" for "Fog Creek Software" and you'll get the idea.

It's a long post, so I'll save you the effort of reading it: if you're practicing Agile and you don't work at Google, you're probably doing it wrong. Here's how Google does it:

• There are managers, sort of, but most of them code at least half-time, making them more like tech leads.

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

• Developers are strongly encouraged to spend 20% of their time (and I mean their M-F, 8-5 time, not weekends or personal time) working on whatever they want, as long as it's not their main project.

• There aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week, including their 1:1 with their lead.

• It's quiet. Engineers are quietly focused on their work, as individuals or sometimes in little groups or 2 to 5.

• There aren't Gantt charts or date-task-owner spreadsheets or any other visible project-management artifacts in evidence, not that I've ever seen.

• Even during the relatively rare crunch periods, people still go get lunch and dinner, which are (famously) always free and tasty, and they don't work insane hours unless they want to.

• Google drives behavior through incentives. Engineers working on important projects are, on average, rewarded more than those on less-important projects. The rewards and incentives are too numerous to talk about here, but the financial incentives range from gift certificates and massage coupons up through giant bonuses and stock grants.

• Google is a peer-review oriented culture, and earning the respect of your peers means a lot there. More than it does at other places, I think. [..] your actual performance review is almost entirely based on your peer reviews, so it has an indirect financial impact on you.

• [Google] has a long all-hands in which they show every single project that launched to everyone, and put up the names and faces of the teams (always small) who launched each one, and everyone applauds.

If nothing else, it's an interesting window into Google's software development process.

The whole FogCreek/Google-Is-So-Totally-Awesome thing is an annoyance. But I have a deeper problem with this post. I think Steve's criticisms of agile are hysterical and misplaced; attacking Agile is a waste of time because most developers haven't even gotten there yet! The real enemy isn't Agile, it's Waterfall and Big Design Up Front. Even "bad" Agile is a huge quality of life improvement for developers stuck in the dark ages of BDUF. I know because I've been there.

Rather than wasting time and effort on discriminating between "good" and "bad" Agile, we should be banding together in the name of Anything But Waterfall. The fact that some maladjusted developer or project manager could use Steve's well-written, reasonable sounding rant as a justification to keep their project in the dark ages of Waterfall and BDUF absolutely kills me. Who is the real enemy here?

I'm not the only person with criticisms of Steve's rant. Dare Obasanjo notes that the talent meritocracy at Google sounds disturbingly similar to the one outlined in Malcolm Gladwell's The Talent Myth:

This "talent mind-set" is the new orthodoxy of American management. It is the intellectual justification for why such a high premium is placed on degrees from first-tier business schools, and why the compensation packages for top executives have become so lavish. In the modern corporation, the system is considered only as strong as its stars, and, in the past few years, this message has been preached by consultants and management gurus all over the world. None, however, have spread the word quite so ardently as McKinsey, and, of all its clients, one firm took the talent mind-set closest to heart. It was a company where McKinsey conducted twenty separate projects, where McKinsey's billings topped ten million dollars a year, where a McKinsey director regularly attended board meetings, and where the C.E.O. himself was a former McKinsey partner. The company, of course, was Enron.

Read the rest of the article; the similarities are truly startling. It's not very reassuring to think that the only difference between Enron and Google is their "Don't be evil" motto. We now have laws in place to protect us from Enron, eg, Sarbanes-Oxley. I'm not aware of any pending motto enforcement acts. Yet.

Wes Felter calls it "a great rant", but also cleverly juxtaposes two of Steve's sentences to illustrate a point:

This nickel-a-line-of-code gig is lame. You know where the real money is at? You start your own religion. [...] There is nothing like it on the face of this earth. I could talk for hours, days about how amazing it is to work at Google, and I wouldn't be done. And they're not done either. Every week it seems like there's a new perk, a new benefit, a new improvement, a new survey asking us all if there's any possible way in which life at Google could be better.

One wonders if the "good" agile at Google isn't just as much of a religion as the "bad" Agile.

How in the world wide web did I not know about the "I Rock at BASIC" t-shirt?

We've all written this program at some point in our careers. But only those of us who truly rock at BASIC.

I recently upgraded my home system with one of the 750 gigabyte Seagate perpendicular drives in order to consolidate a number of hard drives I had on my server. 750 gigabytes is a tremendous amount of storage space in a single drive-- but it doesn't quite get us across the magical terabyte threshold. It's looking more and more like the first terabyte desktop hard drive will arrive sometime in 2007.

Let's take a look back at the other magical thresholds we broke through on the way -- when were 1 gigabyte, 10 gigabyte, and 100 gigabyte drives released?

The data points are derived from this chart; the scale of the graph is logarithmic. The pace of capacity increase has dampened a bit since 2001, but perpendicular technology has gotten us (mostly) back on track.

I remember how excited I was to get my first gigabyte, 10 gigabyte, and 100 gigabyte hard drives back in the day. I've long since stopped worrying about room for applications and even games. It's all media and virtual PC storage these days. Of course, finding things on such a large drive is another matter.

In Quality Software Management: Systems Thinking, Gerald Weinberg proposed a rule of thumb to calculate the waste caused by project switching:

Even adding a single project to your workload is profoundly debilitating by Weinberg's calculation. You lose 20% of your time. By the time you add a third project to the mix, nearly half your time is wasted in task switching.
This can be a problem even if you're only working on a single project at any time. The impact of simply letting your email, phone, and instant messaging interrupt what you're doing can be profound, as documented in this BBC study:

The study, carried out at the Institute of Psychiatry, found excessive use of technology reduced workers' intelligence. Those distracted by incoming email and phone calls saw a 10-point fall in their IQ - more than twice that found in studies of the impact of smoking marijuana, said researchers.

Kathy Sierra wrote a great post comparing multi-tasking and serial tasks and followed it up a year later with a typically insightful post proposing that multi-tasking makes us stupid:

Perhaps the biggest problem of all, though, is that the majority of people doing the most media multitasking have a big-ass blind spot on just how much they suck at it.

We believe we can e-mail and talk on the phone at the same time, with little or no degradation of either communication.

We believe we can do homework while watching a movie.

We believe we can surf the web while talking to our kids/spouse/lover/co-worker.

But we can't! Not without a hit on every level – time, quality, and the ability to think deeply.

Joel Spolsky compares the task switching penalty for computers and computer programmers:

The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That's because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. If you send that programmer to Crete for a three week vacation, they will forget it all. The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve.

I've often pushed back on demands to work on multiple projects at the same time. It can be difficult to say no, because software developers are notoriously prone to the occupational hazard of optimism.

We typically overestimate how much we'll actually get done, and multi-tasking exaggerates our own internal biases even more. Whenever possible, avoid interruptions and avoid working on more than one project at the same time. If it's unavoidable, be brutally honest with yourself – and your stakeholders – about how much you can actually get done under multi-tasking conditions. It's probably less than you think.

Michael Hunter's blog byline is unapologetically over-the-top: making developers cry since 1995.

That's probably why he's such an awesome tester. Well, that, and the braids. Never before in the history of testing professionals have the top and bottom halves of a man's head been so mismatched.*

The absolute worst testers you can possibly have are developers. They're better than nothing. But barely. Even a mediocre tester will make your application better, and by proxy, encourage you to become a better developer. The very best testers will drag you, kicking and screaming if necessary, across the bug-bar threshold. Professional testers force you to become a better developer. Sometimes it's painful. But in a good way, like a heavy workout.

To get an idea of how gnarly the work of a test professional actually is, take a look at Michael's Did I Remember To (test) list. I can barely read the first page without wincing in sympathetic pain. And the list goes on, and on, and on.

Michael recently expanded that list into an entire series of blog entries for DDJ titled "You are not done yet", which are now captured in handy PDF form -- Michael Hunter's You Are Not Done Yet Checklist.

Pick something. Anything. A feature in your favorite software application, your favorite toy, your favorite piece of furniture. Now start brainstorming things you could do to test it. Think of as many different things to do to that object as you can. Come back and continue reading when you’re done.

What’s that? You’re back already? There are test cases you haven’t thought of, I guarantee it. How do I know? Because for even the tiniest bit of something – the Find dialog box in your web browser, say, there are billions of possible test cases. Some of them are likely to find interesting issues and some of them aren’t. Some of them we execute because we want to confirm that certain functionality works correctly. These latter cases are the basis of my You Are Not Done Yet list.

This list is large and can be overwhelming at first. Fear not. You have probably already covered many of these cases. Others won’t be applicable to your situation. Some may be applicable yet you will decide to pass on them for some reason or other. Verifying you have executed each of these test cases is not the point of the list. The point is to get you thinking about all of the testing you have and have not done and point out areas you meant to cover which you haven’t yet.

So don’t quail at the thought of all this testing you haven’t done yet. Instead, customize this list to your context. Scratch off items which do not apply. Use the list as a launch point for finding items not on it which do apply. Use it to organize your testing before you start. Use it as a last-minute checklist before you finish. How you use it is not nearly as important as that you use it in the first place.

Brrr. It's enough to make you hang up your Tab and Fritos to become a console developer. But if you can pass that testing gauntlet, you've definitely earned your stripes as a seasoned software developer.

* I kid! I kid because I love! please don't test my app