The head business analyst on my team read Why Software Sucks by David Platt and liked it so much he went out and bought five copies for the team. So I went into the book with high hopes.
They didn’t stay high for long, though. Platt did a good job keeping the discussion just technical enough to make sense, but not so technical that a non-programmer couldn’t follow along. But I thought that’s about all he did well. The rest of the book is inflammatory and curmudgeonly; he flings around labels like “idoit (sic)” and “marketingbozo” with abandon. He chooses arbitrary examples, and then evaluates them with all the depth of a reflecting pool.
Take an example he comes back to again and again. He likes the fact that when you go to google.com, it automagically knows what country you’re in based on your IP address and sets your locale accordingly and he blasts UPS.com for not doing the same thing and instead making the user pick a locale in its first step. He then goes on to call the programmers at UPS.com idiots and lazy. Well, I like google.com and dislike ups.com for the same reason, but they were created that way probably for far more complicated reasons than he’s admitting to. In particular, what he’s missing is the economic reality of software development, and in particular:
1) Not every company has world-class developers. By definition, the average company must have…average developers. Average developers often don’t know about things like IP address databases based on locales and have no idea how to get to them.
2) If a feature takes 1 day to implement “good enough” and only 1.25 days to implement “great” he would say it’s a crime not to spend the extra 2 hours to get to great. But he’s missing that if you spend that extra 25% on every task then…ding, ding, ding, your project is going to overrun by 25% (if your original estimates were even accurate in the first place. More likely you’ll be 125% late). On an 8-week project that’s an overrun of 2 weeks which is usually not acceptable.
3) Often times, developers want to spend that extra 2 hours to make a feature great, but they are told not to for various business reasons like not wanting to be 25% late.
So, I was disappointed in the book. I was hoping for a good, colloquial discussion of the challenges of developing good software. I was hoping for a book that would give me some good analogies and examples to use on my Mom. But I didn’t.
