A comment I had made a couple months ago on a Joel Spolsky article made it to the Inc. Magazine mail section in the January issue.  Check it out online here.

I don’t disagree with all of Joel Spolsky’s writings. In fact, I probably wouldn’t read his articles and comment so much if he wasn’t 95% accurate and insightful, not to mention a fun read. I was browsing Joel on Software this AM while I waited for Vista’s interminable Windows Update process to complete, and three sections in row hit me right on the Agree Bone:

Paper Prototypes = good

Architecture Astronauts = bad

Child threads = (generally) complex = bad

Anybody who comes in to interview for a programming job and says the word “messaging” is instantly suspect, and I wonder if they aren’t a big-A Architect, too busy to code. I’ve really bought in to the Extreme Programming thesis that progress is made by evaluating working production software, not by any amount of papers, design, prototypes, architectures, etc. And don’t get me started on threading. I’ve been a working programmer for almost 15 years, on business-class software and web applications, and I can count on one hand the times when I’ve had to use any sort of custom thread management code.

Another cluetrain passes Joel Spolsky right on by as he talks in one post about how terrible it is when clients want all sorts of changes right at the end of the project, because they really didn’t read/understand/interpret the spec correctly. He uses himself as the anecodotal customer who got what he wanted — only it turns out, it wasn’t what he wanted. And everybody knows that Joel’s specs are exhaustive, so what’s the problem?

Two or three posts down, he is all agog over Evidence-Based Scheduling — another micrometer wrench in his Gadgetron 3000 toolbox, which is supposed to Solve The Scheduling Dilemma Once and For All. All sorts of Joel’s friends agree! EBS is REALLY REALLY GREAT!

So — which is it? Are schedules and estimates good, nay, even indispensable? Will EBS solve the Terrible Client Dilemma, or will customers continue to come in at the last minute and say “Change these twenty things, because I really didn’t understand how it would all look/work/perform before I saw it.”

For myself, once I accepted the that (a) customers don’t fully understand all of their own requirements early on in the project lifecycle and (b) they appreciate a vendor who can provide the flexibility to accommodate their changes, I became convinced of Agile’s strengths. Joel may not like it, but the Evidence-Based World (EBW) suggests that clients like him are the norm, not the exception.