Joel Spolsky Is Not Magic
Joel Spolsky is treated with reverence by the programming community. It seems like every blog post, comment, interview, Tumble, etc. that has his name associated with it ends up on Hacker News or Reddit. Certainly he has a profound impact on the programming community and many, many people take his words as gospel.
I’ve been reading a lot of Joel on Software lately. Jan Willem Boer’s Joel On Software – A Summary seemed like a good a place as any to start reading through his years of backlogged posts (certainly easier than trying to fumble through Joel on Software’s non-existent archive navigation). I’ve also read all the selected posts that he links to from his homepage (Top 10, New Developer, Rock Star Developer*, etc). He’s a great read and certainly entertaining. However, I’m just not sure how useful or valid his actual development (or business) advice is.
Much of his advice flies in the face of much heralded advice for startups like Getting Real from 37 Signals. His company, Fog Creek, was started with the only goal being “provide a great place for developers to work,” rather than having an actual flagship product, staying lean, and hiring less later.
He says that true software craftsmen spend more effort “getting rare cases exactly right than getting the main code working,” which is pretty much the polar opposite of Getting Real’s advice to start with no, write less software, and forget feature requests. He says you should take extra time to get everything exactly right before shipping, whereas younger, web-focused logic (from people who are actually selling successful web apps) says to race to running software.
This is probably largely due in part to Joel’s history as a project manager for Excel at Microsoft (which he uses as an example in many of his strategy posts). However that advice really only applies to people working on teams shipping large updates in infrequent versions of big, complex software packages. It doesn’t make sense for new startups and web applications to take Joel’s approach.
Just look at his track record after leaving Microsoft. His big program that he uses as an example of what he’s doing right on all his posts, CityDesk, was a self-proclaimed “flop.” He just announced that the Stack Exchange business model was not working, was a mistake, and is being re-tooled. It seems like he loves to give advice, but when he follows it, he inevitably fails. His company’s only successful software product, FogBugz, was developed to be used in-house only and became popular by mistake.
Granted, Stack Overflow is also incredibly popular, and apparently profitable (which makes their reasoning for seeking venture capital nebulous at best). However, it is profitable not as a piece of software, but as an ad-supported community website. It has been allowed to grow organically, with improvements being added quickly and frequently, which is closer to the Getting Real strategy than anything Joel espouses in his strategy posts. Their efforts to turn it into a piece of software that people actually pay for have essentially failed.
I’m not trying to say that Joel On Software is without value or pick a fight with anyone. It just seemed worth noting that following one persons’ advice does not necessarily guarantee success.
* Yuck. Stop calling people skilled in professions “rock stars,” everyone.
I agree.
(that was my comment but the blogging engine thinks it’s too short, so I’m adding this sentence to it).
(This should have been a blog post with pingback instead of a comment!)
You make some points similar to some blog article I read a while ago. The article was a response to his “why do good developers work for sucky companies?” post. The main point was that Spolsky seems to make statements that sound like they should be true and make a lot of sense. Then, when the world doesn’t work the way Spolsky says it should, he assumes it’s because the world is wrong, not him. There’s something to be said for visionaries that try to change the world, but often the world works in an “inefficient” way because the “better” model is too simplistic to handle everything. With respect to good developers working at crappy companies, the main reason is developers aren’t uniformly distributed across the globe, nor are they able to relocate easily. Thus, if the good job is too far from the good developer, she has to settle for a less optimal job.
Ironically, I feel like Spolsky’s view of software development is more like Apple’s than Microsoft’s. Android gets features faster than iPhone because Google is willing to release something with rough edges and smooth them out over time. This leads to a faster release cadence. However, it can also leave the device with half-baked features or features that aren’t as important as predicted. Apple prefers to release on a regular cycle and only includes a feature if they are reasonably confident their implementation is as good as it will get. This typically leaves iPhone fans disappointed with the number of new features, but you can bet that if a feature releases on an iPhone it works well.
I don’t think it’s worth arguing which philosophy is better. If you’ve got adequate capital and you are releasing in a field with competitors, you can’t afford to release half-baked. If you’re short on capital, it’s better to release with some dazzling (if not fully functional) unique features than to run out of cash before you finish. If you don’t have any competitors, there’s no need to apply three coats of paint, clearcoat, and racing stripes: release with the minimum feature set and introduce the polish later! No approach is universally good.