Correctness is not an engineering problem. It's an economics problem. As long as IT Industry is able to extract money from their clients while delivering crappy software, they will keep delivering crappy software.
It could be argued that all engineering problems _are_ economic problems.
(1) Specification (2) Implementation
Specification has always been the primary problem, the simple reason being that we are trying to quantify human desires regarding information flow. As we are finding out, it's non-trivial to say the least.
This goes back to an earlier talk I learned about here and watched just this morning by the outstanding MIT professor Nancy Leveson, https://www.youtube.com/watch?v=WBktiCyPLo4, who has analyzed various engineering problems (including the Challenger disaster) and even published an entirely new methodology for analyzing large-scale systems. Her book can be downloaded for free at http://sunnyday.mit.edu/safer-world.pdf.
Of course, economics factors into everything people endeavor to do these days, but strictly within the domain of creating correct information management systems -- from a purely technical level -- the problems are specification and implementation, in that order. Getting someone to pay for the time and team needed to do the job correctly is a completely different story, and not a pleasant one, it seems.
Namely, is crappy software actually more efficient? Does it deliver more value for less cost? Or is it, instead, that crappy software is a bad value, but markets are not transparent enough, and it is too hard for clients to assess whether the software they have received is crappy and too hard for businesses to convince people to pay them for quality?
If you hire a maid who always manages to miss a spot or two cleaning your bathroom, does it really matter? Your bathroom is a lot cleaner than it would've been otherwise, so mission accomplished in the grand scheme of things.
On the other hand, if you hire a mechanic to overhaul your car engine, you might not be able to tell the difference when you drive it home from the repair shop, but if they did a poor quality job, it is going to come back to bite you. Quality is important even if you need to pay more to get it.
Which one of these two things is software more like? I could see it going either way. Maybe it depends. Maybe there are ways you can cut corners that are a win (more value / less cost) and other ways that are a loss.
It depends on the spot missed: is it contaminated with fecal matter? There you get into the realm of risk management. The problem is that, with software, one bad mistake can leave the user with complete loss of data. Look at Microsoft's recent update debacle; some people lost a great deal of data.
>> Namely, is crappy software actually more efficient?
Never. As the Chinese expression goes: Pay a lot, cry once.
The problem is that the people who pay for the creation of software (i.e. corporate directors) are usually ignorant about all things except for money and the vague desires of their customers. The folks that can specify and implement the systems rarely have the clout to allocate the resources necessary to get the job done well.
>> Which one of these two things is software more like?
Information systems (software that must run over and over again against the same data, often concurrently) are actually engines in that they must withstand stopping and starting; of course, the information engines that run continuously are even more difficult to keep functioning as their uptime stretches on. Therefore, the answer to your question is that software is most certainly more like an engine because information systems are engines, just that their fuel is data (including user input) and their output is information (data made meaningful to human beings) and changes to its information base.
We can all see how the poorly designed information engines of the world accrue ugly cruft that eventually leads to their needing to be "re-built", which, for example for Windows, means re-installing from scratch.
Unfortunately, I don't see either side backing it up with anything that looks like real evidence. It's so complicated to evaluate that I don't think anyone really can prove either way. But you can't not have an opinion since it's an important question, so it seems like people join one camp or the other mostly because it suits their personality or working style.
If they take pride in their work and feel disappointment at the prospect of producing code they can't be proud of, they tend to believe quality is worth it in the end. If they are impatient and like to wrap up one thing quickly so they can move on to the next thing, they tend to be in the other camp.
I myself am in the quality and correctness camp, and I really would love to know that it always pays off because that would mean the way I prefer to develop software is also the most practical and reasonable way. But I can't really prove that it's the right view when you consider the economics.
Oversimplification. Solving a problem just well-enough to live to fight another day is baked into capitalism in a deep way through competition, whether that competition is internal or external. .
I have many many examples from real life, for instance, one from banking; sometimes I have to work with systems that are responsible for 100s of millions of $ in transactions that are just ductaped heaps of crap. They are running on many servers because they continuesly crash and mess things up (literally corrupt data which has to be manually fixed).
The software was written by juniors with a lead tech who only made some web scripts before and all was hurried to the 'finish line' to get more investment.
All of these decision where economic; hire cheap people to show bums on seats, hire cheap management because good management costs a lot keep pushing for deployments even though everything is ill tested because the need for more money.
The result is that the entire team is all day (and night) busy putting out random appearing fires and the average period for an employee to stay is 6 months after which the stress catches up.
Ofcourse they still are doing really well as these type of companies are experts at hiding things like this. Thick rows of sales and account management people to hide the poor execution. Reminds me of IBM in the 80-90s; slick looking suits and shiny boxes but the software they shipped was just pure vomit; it still sold fine (not sure if it changed; I have not worked with them anymore).
Obviously they would be really raking it in if there weren't 40 people 24/7 trying to keep the stuff on the servers from completely exploding.
After a week of hard work in these kind of circumstances, I always enjoy reading HN + Reddit in the weekend and seeing these wide eyed youngsters here thinking that every company does code reviews, unit tests, uses versioning tools (...), not using php for near real time banking backend banking transaction applications (...), kubernetes/docker, microservices, serverless software while in reality it is a microscopic % and very large numbers of money is still being earned through absolute software poop.
Right now there is no reason to think games will even need that level.