Part of our jobs as professional developers is to understand the potential business impact on a feature and not invest time on documentation or unit tests for code that will probably be dropped next week. That said, and not to be harsh—but if you want to be treated like a professional, act like one, and set expectations for how much a feature costs to deliver, rather than breaking your work down into separate tasks and inviting your supervisor to discard the tasks he doesn't understand.
To fix the corporate world is to say "No" more often.
The best thing you can do in this situation, is hold your ground and slow the fuck down. Not because you're a recalcitrant bastard, but because you are the one responsible for quality. Once you learn this, and really internalise it, a lot of things fall into place. Projects are a tug of war over the time / cost / quality triangle. Make sure you're pulling your corner.
But I agree with everything you're saying, which is why I try to get into more test centric cultures when job hunting.
Been there, tried that. I make it as easy as "run this bat file to test everything" in this specific sub-project. And then I watch them make some silly little "test-program" to debug the thing. Not only that, but we discuss a feature in said sub-project that they're implement and I hear disturbing comments such as "I hope it works" or "I hope it all still works after I'm done".
Eventually some of the management may learn how unwise this is, but it can take a long time, especially when many projects don't end up being successful/used by intended users anyway (which is its own drag on morale). I don't work in this environment anymore, thankfully.
Maybe it's because I've worked in smaller teams but there was no real pressure to deliver a month earlier. When we presented to other people in the company they don't really care if we covered 38% of cases this month or 42%, they simply don't know what those numbers mean.
Somebody somewhere said that:
"Estimate the time it takes to finish the project. Then multiply that by 8"
Surprisingly, this usually lands in the correct estimate. Best advice ever.
Yeah, I know that it's not likely to work...
It doesn't make sense in the long run to do this "fix, patch, fix, patch" non-sense .. but still companies need to ship shit to some deadline, so we do it.
80% of workplaces are like that.
I think its the incentives of billable hours that does this. They want low estimates, so they can win the work at all costs. They have to do it because other companies also underestimate. That or they think pressure motivates developers, but it really results in terrible code.
I personally advocate using accurate estimates, then applying a discount if you have to.
Underestimating is very common with programmers, yeah, because they think they can do it in the given time, but in reality that almost never happens, at least to my experience.
What is an accurate estimate ? It changes all the time when new pitfalls and problems are discovered during the development cycle. So accurate estimate is something that almost all the time more than the original estimate, if you think logically. So better to just multiply by some factor that is realistic.