Although it's a fun read, it's a classic example of diving into coding without giving a project it's due diligence. There's nothing that's derailed my projects more consistently when I started out as not understanding the user's needs. They'll never tell you what they want, only what they don't want after you deliver something. I think that's the key difference to an experienced dev/BA. One who can actually sit with…
The flip side of this is that when stakeholders/customers don't know what they really want or need, you can labor in the "requirements phase" for months. My team spent 900 hours last year just getting a functional spec and high level SRS together for a project that hasn't happened yet. Why hasn't it happened? Because at the end of the 900 hours, we presented our estimate (about 1100hrs) to the customer and he balked…
Completely true is the thing with the superstars. I knew one myself, a genius in warehouse management systems. If I had him on a project, it went smoothly as anything. if I didn't I stayed in development hell for months. But seeing this guys workload, he wasn't off any better.
But in retrospect, the general direction the organisation took at my last employer wasn't that bad. Execution lacked, so.