A few months back I took over a job from someone who was quitting for the same reasons I am here today. The job involved developing an in-house application that would be used mostly by the staff. The person abandoning the project was not even close to finishing the application but got sick and tired from stress, extreme deadlines, etc. At the time it seemed like a great opportunity. I have a lot more experience than the previous dev and the project didn't look that hard to complete, so I took the project.
The meetings went great; people listened to my advice. We made big leaps in quite a short time. Bugs were fixed, the UI got an overhaul, a lot of the code got refactored with re-usability in mind. The application finally started to look and work like something.
After a while, new features were requested, planned and executed. As the time went on, the manager kept posting new features requests that he wanted to be done in an extremely short period. For example a fully featured, production ready fleet management system in 14 days, starting from scratch.
NOTE: The manager has little to no technical background.
This came with the consequences that either I deliver poorly written and untested code, or that I don't make the predefined deadlines. Two horrible situations IMO.
I tried to point this out during meetings, but it was waved off with reasons like: "The end user does not see the tests, as long as it works and looks good it's fine, time to market is more important." And the last reason, the one I hate the most was, "Such a smart developer like you, has to be able to do that in x amount of time."
How could I make clear that a production ready application or features are not built in a short amount of time? That a prototype is not the finished product, and that code coverage, testing, releasing betas, etc. is extremely important to deliver quality?