Prisoner of ice

All software companies talk about quality of their products. Quality is such a buzzword - sometimes I think that it doesn't mean anything at all.
However, quality means a lot to developers. Many developers that I know really care about products that they create, often against their managers and their companies. I understand when managers decide that they cannot spend more on some particular product, but I cannot understand a situation when a company makes developers work on some unimportant documents instead of making them focus on their work and implement the real thing.
I often encounter a situation when best developers in the team are assigned to create some specs in the early stages of development (often they have to analyze problems that they don't fully understand before the implementation), and people who are responsible for the actual implementation are unexperienced folks that have to learn how to solve problems during the project.
During the development everybody is in such a hurry that all tools and practices that are necesarry to create quality product are abandoned. This means no unit tests, no code reviews, etc. The project just flows. Because people who are developing it don't have any experience, they cannot solve even simple problems, they make obvious mistakes, copy code and everything becomes an awful mess. The project runs behind the schedule and, what is more important, it doesn't ensure any quality at all. After struggling with deployment, the product goes public and bugtracker is filled with bugs.
Unfortunately, because the budget was exceed, all funds are cut and people working on the project don't think about ways to heal it, but they start reading the specs, trying to persuade the client that the project meets specification requirements.
In this stage we can hear a bunch of silly questions, such as:
Do we have to log errors?
Do we have to support firefox?
Do we have to show error messages to users?
Do we have to validate input?

Well, the specs don't say anything about it. What's the conclusion? The project is just perfect. The only problem is that it just doesn't work.
After wasting lots of time on trying to vainly persuade the customer that it's not a bug, but it's a feature - the company faces the fact that they have to solve these problems. Unfortunately, as I've said before, they don't have any funds left. What is more, they discover that time spent on fixing the product generates loss, but if the developer does nothing or does not report his time on this particular product, no loss is generated. Now, the biggest issue is reporting the time spent on fixing the product. On paper it is better to sit and do nothing than to fix the damn thing.
It's like putting handcuffs on developers' hands. You just can't do anything. You know how to fix it, you have the idea, you know what you need, but you can't do it because, magically, the moment you report your time on the project, you start generating loss.
And the so story goes...

In my opinion, these problems are encountered in companies that are focused only on making money and they forget that they are making software. In the end, developers have to think about the budget and all that stuff around cost management, not about making great software. As the result, software is crappy and the income is far smaller than it was initially expected.
I have no experience running any company and maybe I am totally wrong, but I can tell bad software when I see one. And when I see developers that are prisoners of their projects, managers and procedures, I wish all project managers would be like Ron Jeffries or Joel Spoolsky. I wish developers could create applications that delight customers, create code that speak for them, have specifications consisting of test cases and work with the best programming teams in the world ;).