I thought it might be that she didn'tt mesh with the tightly knit social fabric of the team. And that may be true to some extent, but it did not mitigate her observations.
A week ago, another colleague outlined similar difficulties coping with his developers. In a typical situation, one of the developers spent a large chunk of budget making re-implementing an unnecessary object-database mapping component in a Grails project, modelled after a Ruby component. Then the developer left, leaving the team with a piece of unfinished work that was unsupportable, fragile, and locked the system into unnecessary dependencies on antiquated libraries.
As for myself, I appreciate a good John Wayne style epic, knowing that the real life phenomena is much dirtier and more mundane at the same time. I dislike the metaphoric reference for reasons that I shall for now only briefly summarize, but perhaps a better model is the ranch hand.
I interviewed at an institution's development shop recently. As far as I could tell, the prospective employer's development practices were ambiguous and very reactive rather than well-defined and proactive. For instance, they did not test using any sort of automation, hadn't adopted any higher level frameworks or tools, or indeed could not communicate anything resembling a defined process. They also self-admittedly spent a good deal of time in fire-fighting mode. So their code was highly specialized, very one-off special-case stuff, and their processes non-existent. Consequently they don't mature as developers or as an organization. That's the real cost of substituting immature cowboys for ranch hands.
I'm fairly certain that the above describes the preponderance of development shops. It is a problem for our industry, one which reflects very poorly upon the status of programming as a profession.