[Pr3fix]

Because in a lot of ways those practices don't further the end goal or bottom line of the business. They don't meet business needs. As a developer, I think we both can agree that these things make our (developer) lives easier, but they often don't help the bottom line of the company. I know some dev will retort this, but if I was wrong then companies would be mandating these practices top down.

[mgkimsal]

It's primarily perspective. I just came off a short term project which... yeah, it worked, but it's a disaster (but.. yeah, still working, technically).

4 years of no version control, no test environment for at least a year (it was shut down then never turned on again), no written docs, no written tests (and for periods of time, no backups). This software manages and controls 9 figures of USD annually.

The 'bottom line' was/is always "i need a form that does X" and "I need a form/report to show Y". Yes, the immediate short term goals of the business worked.

The entirety of the codebase has been hardcoded to work with library calls that were known tech-dead-ends years ago.

The business now needs someone else to come in and manage things, because the original guy left. The business is now up a proverbial creek, because everything was in someone else's head. TDD/testing/docs externalizes some of that, and does have real business value, but it requires someone to be able to look more than 6 months in to the future with respect to tech decisions.

Their bottom line will be hurt over the next year because they will be needing to pay far more to repair the tech debt, and it will mean fewer new things get done (or.. they'll pay even more for that). So... "business value" needs to be defined as to how you're measuring it, and 'short term' is always easier than 'long term'.