I see two types of engineers: the build-it-quick lot and the build-it-right lot.
The first is ideal for companies where getting an idea to market as fast and cheap as possible is ideal. They use abstraction tools which are not robust but allow fast and flexible prototyping and a "MVP" to come out in a month. The end goal is to get enough traction for an acquisition, the acquirer can worry about rebuilding things properly.
The second lot are greybeards, with or without grey or beards. They will tell managers annoying things like "I can't commit to this deadline because I don't know, right now, the order of magnitude of time this will take". They work for larger companies or more ambitious projects where correctness and robustness is valued, like in banks or designing embedded systems or machine vision companies. They also tend to cost more because their skillset is bid up by large companies with deep pockets.
Both sides have a point.
It's probably more important to push the MVP out today before you run out of money than to have a truly scalable, Boyce-Codd NF compliant database underlying it in just a few more months, if you're building a simple company in a busy space, and worrying about customer data protection when you have no customers is understandably not at the top of the priority list for your investors.
On the other hand, it's probably a bad idea to build your hospital life support system in RoR, or your multinational financial reporting infrastructure in 2 weeks of "hacking".