tilly's suggestion of Rapid Development is a great one. What you described is pretty similar to the case study. I'd also add, that if you can't sell those ideas upstream, try to protect yourself by insisting on clear requirements from your manager and have them push that message upstream. It's bad enough when you have to work in that kind of environment. Doing it while shooting for a moving target is a huge morale killer.
in reply to Re: Re: How do you avoid "Code Burnout"?
in thread How do you avoid "Code Burnout"?
Personally, I think there's a pretty close relationship between burnout and morale/depression. When I can see the finish line, I have boundless amounts of energy. It's when I seem to take a step back for every one forward that I notice the fatigue of burnout. Once that starts, it's pretty hard to produce at my best. The longer I feel I'm running in place (or going backwards), the more burnt out I get.
You may not be able to communicate that all the way up your management chain, but if you can get through to your manager, then it may help control the parts of the project that directly affect you.
If this sort of thing becomes a habit in your company and you find you're getting burnt out freqently, then you have to look out for yourself and consider walking away. I did that in January. (The factors that caused the burnout in my other post just got worse in the ten months since my two week break.) The time off was great and I finally opened that copy of Teach Yourself Perl in 21 Days that was on my bookshelf for two years. Within four months, I was at a new job and that's going pretty well.