Tuesday, March 27, 2007

Don't Misquote Me to Create a Straw Man!

OK, I can't let this pass.

The ServerSide wrote an article, summarizing both mine and Venkat Subramaniam's talks at The ServerSide Symposium last week. It's a reasonable summary, with a few details left out (that's why it's a "summary").

But then, Cedric Beust takes the summary and constructs a agile development straw man to beat up. And, like many straw man arguments, he takes lots of stuff out of context and makes his own conclusions not supported by the original talk.

The first thing he gets wrong is the fault of the summary. Early in the talk, I clearly state that the best way to get good software is to interact directly with the users. And I give an example from my project history of the best project experience I every participated in, where the developers literally sat in the middle of the users. Every time we had a question, we just got up and resolved it directly with the users. It was project heaven.

But most corporate environments won't give you such direct access to the users, because the users are after all there to get work done. Thus, you must have user proxies. And that's where the business analysts come it. Perhaps at ThoughtWorks, our business analysts are different from the "typical" ones (I know our project managers are). The best business analysts are direct proxies for the users. They understand the users concerns and a little about technology. During the talk I also made the point that good business analysts prevent "paving the cowpath", suggesting innovative business solutions to problems rather than "that's the way we've always done it".

When I say that business analysts participate in the estimation process, that's because we can't get the users directly.

Do you know the difference between a good developer and a bad developer? A good developer can give you an estimate of the time needed to complete a task. And the better that developer is, the more accurate their estimate will be. If I ask a developer "How long is it going to take to do this?" and he answers with "It's very complicated", I want him off my team.

Another point I made in my talk is that, regardless of developer, you can't ask developers "how long will this take". Every project is different: in a 2 man project with no meetings and direct access to users, each developer will get more done in less time. In a project with 16 developers and a 2-hour status meeting every day, each developer will be much less effective (this has been known since Brook's The Mythical Man Month). But that is constant is the relative complexity of the story you are trying to complete. Relative to the other stories, not the entire universe. This allows developers to hone their estimation skills because it cuts down on the number of variables they have to hold in their head. This is the closet you can get to an objective measurement of the work required to complete a piece of software.

We don't need agile consultants and book authors to sell us vague and unproven metrics along with rigid guidelines that your team must embrace without any questions.

Ironically enough, we agree wholeheartedly about this, but he doesn't seem to know that this is exactly the point of my talk at The Serverside Symposium. The whole point of the talk was that we need real metrics like passed tests, real reconciliation between estimates and actuals, and binary completion criteria. The article makes that pretty clear, but that doesn't contribute to the weak straw man, so Cedric conveniently left that out.

What's most frustrating about Cedric's rant is the implicit assumption that "agile" is this vague concept that no one seems to be able to define. Yet, at ThoughtWorks, every single project is agile to some degree (and where we control everything (like fixed bid projects), it's pretty close to Extreme Programming). And we have a really high success rate, way above the industry average. I've been around for a while (one of my colleagues once told me that I was old enough to "add diversity to the company"), and I've used a bunch of different methodologies. One of the reasons I'm at ThoughtWorks is because we use proven techniques for building software, and we're damn good at it, making it a much less frustrating place to work.

Wednesday, March 21, 2007

DSL Podcast on No Fluff, Just Stuff

As my regular reader(s) know, I'm big on Domain Specific Languages, and have been talking and writing about this style of development for a while. During the course of last year, we recorded some PodCasts at some of the No Fluff, Just Stuff shows. One of those shows was Chicago, where I recorded a PodCast about my feeling about DSLs and this approach to building software using this technique. The PodCast has now appeared on the No Fluff, Just Stuff web site, for your listening pleasure.

Saturday, March 17, 2007

Anthologization Redux

Well, it's that time of year again: the No Fluff, Just Stuff Anthology, Volume 2 (The 2007 Edition) is at the printers, undergoing the conversion from thought to dead trees.

NFJS Book cover
Just like the blurbage on the back says:

Once again, some Sixteen of the world's best trainers and speakers are writing chapters on things they care passionately about. You'll find topics from the latest conferences including Groovy, JavaScript, Continuations, Web services and REST, JVM Byte Code, and Agility

These essays are a summary of the latest thinking in the industry, and range from the philosophical to the tutorial, covering the topics that the writers felt were the most important for readers today. If you feel like the neatest technology and latest ideas are passing you by, this book can help bring you back you to speed.

It's all good stuff, without any fluffy filler, as these essays are based on presentations given at the incredibly popular "No Fluff, Just Stuff" symposium series. Twenty-six times a year, the symposium visits a city and the speakers and attendees share ideas and perspectives. The speakers are all internationally known experts in their field.

So, to out and buy one as soon as possible (in a book store near you in early April). Or, order it directly from the Prags or at Amazon. In fact, I recommend that you buy two in case you loose the first.

Of course, I was intimately involved in its creation, but this is a really entertaining read (the main reason I like editing the Anthology is because it means I can read the essays as soon as possible).