Having worked on both sides, I dislike the author's depiction of high-end consultants as "scientists" as opposed to the "engineers" who ship things. These "scie

Having worked on both sides, I dislike the author's depiction of high-end consultants as "scientists" as opposed to the "engineers" who ship things. These "scientists" who sell their models of how software development is supposed to work are mostly, in my experience, hucksters. They haven't actually figured it out (no one has), but there's a market for software processes because software is hard and unpredictable, many people want to be told how to do it, and some are prepared to write cheques. People may go into the authority game with good intentions, valid experience, and talent, but without the discipline of hands-on work on real systems (and no, an occasional trip to the client doesn't cut it), it's too easy to fall for one's own hype. All the more because you are surrounded by people who are paying you to tell them what to do and thus themselves have a vested interest in believing that you know. The deep problem underlying this is that we are a long way yet from having large-scale economic organizations suitable for developing software efficiently. My money's on small autonomous units (a.k.a. startups), but that's still a minority view. There's an impedance mismatch between how most people want to fund and run software projects, and the work itself. The markets this mismatch creates (like the market for software processes) are unhealthy ecosystems in polluted environments. But it is very difficult to see that from the inside, especially when you're a high-end consultant with more money and higher status than lowly practitioners. I know of only one way around this conundrum of how to tell bullshit apart from knowledge, and it goes like this: write nontrivial programs and show me the code. Then we can talk.