I was taught all that in college too. But, as a working analyst, my company *never* allocates enough time to code the way it should be and usually barely enough to get it actually working.
If you were working at a construction company, say, and your were given insufficient time or resources to build a building the proper way, would you continue working properly until time and resources ran out, not knowing if that meant you would get more resources or get fired, or would you cut every corner you needed to until you were certain you'd finish the building on time.
In both the construction industry and in the software industry, there are individuals and companies that will cut whatever corners need to be cut to deliver something within unreasonable requirements. The critical difference is that in most other industries, that isn't a source of
pride.
There's a saying in engineering:
code is written in blood. What that means is that the rules and regulations we follow as engineers are often only written after a mistake kills people; then and only then do we decide that maybe we shouldn't do that anymore. In that respect, the engineering disciplines are rather dumb, in that in a sense, they only advance through literal human sacrifice.
Programming as a discipline is, by that standard, brain dead. Programming failures have caused deaths just like any other technical discipline. But unlike basically
all of them the software development industry as a profession has never adopted
a single professional rule ever regardless of blood spilled. Software development as an industry has no actual rules explicit to it at all, the odd methodological standard notwithstanding.
Sometimes, when I say this, someone will say that software is too complicated to be regulated by the same kinds of rules that regulate all other forms of engineering. My stock reply to them is:
only the way you do it.
