When you’re working on a monolithic system and automate tests for it — which you’re supposed to — the time it takes to run the whole suite grows proportionally with the size of the system. In a significantly large system, the whole run might take many hours or a few days to complete.
You don’t start building a house without an architecture, yet when it comes to software development, most projects don’t have any well-defined architecture.
Many people attribute the difference in approaches to the fact that it’s hard to change the house that’s half done while software is malleable and hence can be changed easily at any moment.
But that’s not true. The further down the road a software project is, the harder and more expensive it is to change its architecture. It’s still doable, but it unnecessarily costs much more than it would’ve cost if some time would’ve been spent on the initial architecture.
There are multiple reasons companies hire cheap programmers. Some of those reasons are valid but there’s one reason that’s not only invalid but also dangerous. That reason is hiring them just because they’re cheap.
During my career, I have personally inherited and took over a few codebases written by cheap mediocre programmers. The codebases were so bad they negatively affected productivity of the new teams for years.