4 ms·

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

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.

caente 8y ago
> Correctness is not an engineering problem. It's an economics problem It could be argued that all engineering problems _are_ economic problems.
bluGill 8y ago
Note that as an economics problem is it important to ask if it is worth the cost. Most software doesn't actually need that level of correctness. As we get more and more automated more and more software will get there. Right now there is no reason to think games will even need that level.
adrianmonk 8y ago
If you think of it as an economics problem, it raises a question, one which I'm not completely convinced I know the answer to. 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.
- OneWordSoln 8y ago
  >> If you hire a maid who always manages to miss a spot or two cleaning your bathroom, does it really matter? 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.
  - adrianmonk 8y ago
    Thanks for the thoughtful reply. I feel like our industry is in two camps right now, one that firmly believes quality always pays off and one which believes it is more of a luxury. 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.
OneWordSoln 8y ago
I'd say it's two-part problem: (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 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 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.

caente 8y ago

> Correctness is not an engineering problem. It's an economics problem It could be argued that all engineering problems _are_ economic problems.

bluGill 8y ago

Note that as an economics problem is it important to ask if it is worth the cost. Most software doesn't actually need that level of correctness. As we get more and more automated more and more software will get there. Right now there is no reason to think games will even need that level.

adrianmonk 8y ago

If you think of it as an economics problem, it raises a question, one which I'm not completely convinced I know the answer to. 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.

OneWordSoln 8y ago
>> If you hire a maid who always manages to miss a spot or two cleaning your bathroom, does it really matter? 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.
- adrianmonk 8y ago
  Thanks for the thoughtful reply. I feel like our industry is in two camps right now, one that firmly believes quality always pays off and one which believes it is more of a luxury. 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.

OneWordSoln 8y ago

I'd say it's two-part problem: (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 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 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.