[Silhouette]

> The ability to convert detailed specs into code is a fungible commodity.

I strongly disagree. The point of a commodity, in the economic sense I assume you meant, is that one item is just as good as another. You pay a certain amount of $$$, and you get a certain amount of Stuff.

IME, one piece of code implementing a particular requirement is very much not the same as another. Assuming otherwise is the kind of naivety that leads managers to make the sort of mistakes we've been discussing.

> I see the issue more as a failure by the good experienced coders to differentiate themselves in the marketplace than a conspiracy against old people. [...] Tell me why you're worth more.

If you believe code is a commodity, you don't want to hear and won't believe the answer anyway.

[datapimp]

I love that you're fighting the good fight, but to these people who run things, code is in fact a commodity and so is the person producing it. From the owner's perspective you buy coders low, you maximize their output and sell it high, accumulate the difference, and repeat. If you're a more liberal owner, you buy them free lunches and build up a "culture", let them wear sandals, send them to conferences, tell them they're not little units to be counted, but at the end of the day these pretty lies are just costs -- costs, which may or may not yield profit over the long run.

As a coder, and somebody who loves the craft and identifies strongly with it, I "disagree" with this relationship ( as much as that is possible, since nobody asked me to vote on it or anything ) and I think it is dehumanizing. But wishing it away or romanticizing what we do, avoiding the fact that we are commodities just like every other worker in a corporate enterprise is just a terrible strategy for overcoming it.

I like what the guys at http://www.bettermeans.com are doing with the open enterprise governance model. I don't want human activity to continue the process of commodification, and this is a big step taken to change course.

[Silhouette]

Oh, I understand the problem; it was "management error #2", I think. And I understand that discussing it here will have little real impact on the managers concerned. I got off that train personally and no longer work as anyone's employee.

I hope that my contributions to discussions like this will encourage others to do the same, and that maybe, if those people one day have employees of their own, they will be a little smarter than the managers of today and the industry will be better for it.

In the meantime, I don't see why we should place any faith in the established practices of managers who, as an industry, run more projects that fail than projects that succeed. Can you name any other industry where it would be considered acceptable by the market if over 50% of the products bought failed, even if the costs ran to millions? I sure can't, it's just that the management idiocy is so widespread in IT that the market seems resigned to the inevitability that whatever they pay for will be crap that doesn't work properly.