There used to be an idea to design, create pseudo-code, and real code would be a small percentage of the development process. While the idea is great for designers, it is terrible for programmers. It removes most of the excitement of coding and the magic of making things work. Design is a great idea that doesn't work in the real world for most programmers.

Instead, the idea of frameworks and standards took hold. Though frameworks and standards are misapplied and often just plain wrong, it does give some form to the code and is at least sometimes better than complete freedom. A compromise of sorts.

For those inclined toward personality typing, on the MBTI, in my experience, programmers are Ps, designers, Js. Ps are better programmers and making things work. Js can do that, but not as well. Ps also have an easy time making disparate things work together, often leaving Js in the dust. Js are better designers and will prepare fallback plans well before Ps even recognize there may be an issue. Recognizing others strengths and compromising is the best way to complete our goals.

Today, rapid development has taken on new meaning. It means, as stated, the customers don't even know what they want, and yet the code must get started right away. One solution has been new approaches to writing fast code. But, while this works great for the UI, it wreaks havoc on good code. To make matters worse, managers often do not understand the difference between good and bad code. This leaves the programmer with no recourse, and management with "unforeseen" problems.

If the programmers are trusted by their managers, such as can happen over time, there's good chance the programmer's opinion will be trusted and more time can be asked for and granted. Perhaps not always, but often enough to make it workable.