Wow. An excellent Meditation that touches on many, if not most, of the sore points in our profession. I'm only going to elaborate on one point.

I think it is time for us to start insisting on Q&A and development life cycles that mean something.

How would you suggest doing that if you're in a company whose CTO blames the developers for shoddy work when each developer has 27 days from being handed requirements to delivery into production, regardless of the scope of change? (Yes, I've been in that situation.) Expectation management is not just between developers and consumers. It's between developers and "Other", for all forms of "Other". It's often between developers and other developers.

Furthermore, just like in any industry, there are bad programmers and there are lazy programmers and there are disinterested programmers. There are programmers who've been told "You're the programming guy, go fix XYZ before the demo this afternoon." XYZ happens to be in a language you don't know on a platform you've seen once before. But, you're the programming guy, so you need to solve it. (And, yes, I've been in that position, too.)

In my opinion, Management is the one that is causing the issues. Now, they may be doing so because consumers have been conditioned to expect stuff to be half-assed, so management has to beat the next guy who will make his programmers do things "The Wrong Way"(tm). The only way to do that, it seems, is to be "wronger" than the next guy.

So, I guess the expectations that need to be managed isn't to reduce the "Gimme more features" cry but to increase the "Gimme stability" cry. We need to make J. Q. Public realize that the best features are useless unless the foundation works.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.