Well, it's true that sometimes projects fail because people uncritically follow the advice of respected authorities. On the other hand, sometimes projects fail

Well, it's true that sometimes projects fail because people uncritically follow the advice of respected authorities. On the other hand, sometimes projects fail because nobody respects authority. Every single decision, from the compiler to the database vendor to the lunch menu, is challenged by the free-thinkers on the team and then debated to death. Eighteen months go by, and the software doesn't ship. Sometimes projects fail because everyone loses the plot. Determined to avoid being trapped by the constraints of a standard methodology, but unable to find the time or the talent to develop, document, and teach a methodology of their own, the leaders fall back on the classic IT solution: handwaving. There are no established authorities or written specs, and processes like QA or release engineering evolve from week to week and are passed on by word of mouth. Eventually, the one person who knew how everything worked accepts another job, everything falls apart, and the software doesn't ship. Sometimes projects fail because the people on the team are demoralized. Without a successful company to model themselves on, they fear that they've gone down a dead end. Without a community or a written argument to back them up, they are hesitant about proposing their new ideas, all of which sound stupid. ("Yes, we should write tests for code that hasn't been written yet." "Yes, we should ship version 0.5 even without those 'critical' features, to start getting feedback.") The employees sit around in their cubes, playing Tetris and looking forward to happy hour, and the software doesn't ship. And, of course, sometimes projects fail because the team was badly put together in the first place. Anxious to avoid hiring "hero worshipers" who "do not think for themselves", the boss doesn't ask the interviewees what they think of Paul Graham, or the Joel test, or XP, or Martin Fowler, or Bruce Tate, or DHH, or Seth Godin. Five weeks later, the "team" consists of a Java developer who secretly prefers Rails, admires 37signals, and wants to work as the back-end guy at a YC-style startup; an Oracle-certified .NET developer who wants to be a VP at a $100-million IT consulting firm; a designer who knows a little PHP and wants to work part-time; and a marketing person who used to work for Procter and Gamble. These folks can't agree on anything, and the software doesn't ship. So, on balance, I think that so-called "hero worship" is pretty useful, and the IT industry needs more and better heroes. (Though I prefer the term "leaders".)