5 ms·

Is there some reason to believe that with enough money software could be bug-free? Developers are often guilty of just refactoring for no particularly good rea

by bdamm 11y ago

Is there some reason to believe that with enough money software could be bug-free? Developers are often guilty of just refactoring for no particularly good reason other than their personal sense of aesthetic, which can lead to endless (and destructive) refactoring. More money also makes people design lazy, so that instead of finding clever ways to reduce effort and improve uniformity, you just have everyone make their own forms.

diafygi 11y ago
There is. See the space shuttle software. http://www.fastcompany.com/28121/they-write-right-stuff http://www.fastcompany.com/28121/they-write-right-stuff
- FigBug 11y ago
  And yet it still couldn't handle flying over new years: https://www.newscientist.com/article/dn10459-y2k-like-fears-create-shuttle-scheduling-crunch/ https://www.newscientist.com/article/dn10459-y2k-like-fears-...
  - gsnedders 11y ago
    It probably could and in testing it could, they just decided not to find out whether it would really work properly when seven people's lives depended on it working. If you can practically avoid an edge-case you haven't ever relied on in decades before when people's lives depend on it, not risking it doesn't seem that crazy.
  - chris_wot 11y ago
    Actually, they could but given the fact that the shuttle is not much different to strapping equipment and people to a gigantic bomb they seem to have decided that even though exhaustive testing found no issues a small change in the schedule was less risky.
- nightski 11y ago
  It isn't a practical solution for the majority of software out there. I also think that while their method works, it is pretty archaic. Looking to the future I hope we can find a way to achieve the level of results they do, without the ridiculous effort and cost.
  - pron 11y ago
    > Looking to the future I hope we can find a way to achieve the level of results they do, without the ridiculous effort and cost. That is unlikely. For computational complexity theory reasons, writing correct software is extremely computationally expensive (regardless of whether or not the language is Turing complete). In fact, it is "the hardest problem in computer science", in the sense that any problem with bounded complexity can be efficiently reduced to software verification. Even verifying finite-state-machines (the simplest computational model) is PSPACE-hard. What we can do is find many ad hoc ways, each helping to some extent with some kinds of correctness properties.
    - nightski 11y ago
      Most software problems I encounter in the real world ARE of bounded complexity, and they can be reduced to software verification. But this is still a very tedious process and there are significant gains to be had by making this more accessible without having to solve the hardest problem in computer science.
      - pron 11y ago
        Certainly. It's just that there cannot be one (or a few) advances that would make writing correct programs generally easy. We can concentrate on domains (in the safety-critical embedded world this is almost a solved problem for some kinds of applications thanks to the invention of synchronous languages in the '80s, that make formal verification relatively efficient). We can also address some "internal" properties, like memory safety and transactions, that on the whole might make writing correct programs easier (though not provably correct).
  - adrianN 11y ago
protomyth 11y ago
> Is there some reason to believe that with enough money software could be bug-free? NASA with the Space Shuttle software came pretty close. http://history.nasa.gov/computers/Ch4-5.html http://history.nasa.gov/computers/Ch4-5.html
- kruczek 11y ago
  In case of NASA, it's not only because of money though. It's because of a very rigorous process of designing and testing their software, sufficient time to follow this process, as well as writing a single product for a single customer. Of course money enables such process, but alone it is not sufficient.
marcosdumay 11y ago
Enough money and the goal of making software bug free can make it bug free. But enough money and the goal of making it infinitely flexible, having all the possible features, or the most perfect UX that a team can not decide on what it is will only make the software more bloated than it's reasonable, and fill it with bugs.
- deleted 11y ago
  [deleted]
panic 11y ago
I think "bug-free" software is a distraction. It's fine to make the occasional mistake. The real problem here is that nobody seems to take these mistakes seriously. Everyone seems to expect software to be occasionally broken, including the people writing it.
- catnaroek 11y ago
  Aren't your second and last sentences in conflict? How could we not expect software to be "occasionally" broken, if it's "fine" to make the "occasional" mistake? Of course, making mistakes is only human, but mistakes should never get past the build process (compilation, automated testing). Any mistake that does reflects an error in your design (not making your code amenable to verification) and/or your process (not capturing requirements in tests).
  - panic 11y ago
    Yeah, using "occasionally" in both places drew a parallel that I didn't intend. We can expect people to make mistakes without accepting broken software. As you say, there are processes that can reduce the impact of mistakes on the final product. I think a culture of taking issues seriously is also important. Small mistakes are easy to make, but they're easy to fix if the organization has a good way for them to be reported and allows people to spend time fixing them.
forgotpwtomain 11y ago
> Developers are often guilty of just refactoring for no particularly good reason other than their personal sense of aesthetic, which can lead to endless (and destructive) refactoring. There are lots of good reasons to refactor - if indeed frivolous refactoring is more prevalent I would think this kind of opinion should be supported by a source/reference.
pmarreck 11y ago
> that with enough money software could be bug-free? According to empirical studies, practicing TDD leads to a 90% (yes, that number is correct) post-ship bug reduction at an upfront cost of 15-35% more development time. Which seems like a pretty good tradeoff, to me. (And I've experienced it firsthand.)
- DomreiRoam 11y ago
  Do you have any links on this studies?
  - pmarreck 11y ago
    Here is the infamous Nagappan TDD paper from Microsoft Research http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.... Also discussed in this infoq article http://www.infoq.com/news/2009/03/TDD-Improves-Quality http://www.infoq.com/news/2009/03/TDD-Improves-Quality Here's someone's thesis paper on it, with data: http://www.nomachetejuggling.com/files/tdd_thesis.pdf http://www.nomachetejuggling.com/files/tdd_thesis.pdf There's also interesting discussions like this http://programmers.stackexchange.com/questions/206355/the-relative-cost-efficiency-of-acceptance-test-driven-development http://programmers.stackexchange.com/questions/206355/the-re... "it is my experience that the value proposition for TDD grows exponentially as the time and resources involved in a project grows linearly." This has also been my own experience. This person's comment also is interesting and has data http://programmers.stackexchange.com/a/210756 http://programmers.stackexchange.com/a/210756 Some of the above is empirical (read: scientific, no-bullshit) data. My opinion on it has grown to the point that I think TDD should literally be inseparable from programming, and the two together should simply be called, "programming." Lacking any unit tests whatsoever (TDD or otherwise) should be called, "taking stupid, extremely hazardous risks to save a little time, like reading your phone while driving" I've not found a programming task in at least 5 years that wasn't waaaay better-written when done via TDD. Some things, like IO, can be a challenge to unit-test, but that's why we have great ideas to solve that like Gary Bernhardt's awesome "Boundaries" talk https://www.youtube.com/watch?v=yTkzNHF6rMs https://www.youtube.com/watch?v=yTkzNHF6rMs
lmm 11y ago
> Is there some reason to believe that with enough money software could be bug-free? Yes. It's pretty easy to write provably correct software, just expensive. > Developers are often guilty of just refactoring for no particularly good reason other than their personal sense of aesthetic, which can lead to endless (and destructive) refactoring Not my experience, but even if so, if you require your software to be proven correct then it won't matter - any refactor that breaks it simply won't be accepted. > More money also makes people design lazy, so that instead of finding clever ways to reduce effort and improve uniformity, you just have everyone make their own forms. Um what? What does this have to do with anything?
- majewsky 11y ago
  Once you have provably correct software, the much harder problem is provably correct hardware. :)
  - lmm 11y ago
    Shrug. We have provably validated diodes AIUI. If you can get provably correct basic components you can build up complex components using the same techniques as in software.
  - hyc_symas 11y ago
    Good point. But choose the wrong hardware and you can never have provably correct software. E.g., the Intel x86 ISA makes all x86 processors impossible to prove correct. (there are 2^120 possible instruction encodings - the universe will die heat death before anyone could verify all of them in an implementation http://www.emulators.com/docs/nx06_rmw.htm http://www.emulators.com/docs/nx06_rmw.htm )

by bdamm 11y ago

diafygi 11y ago

There is. See the space shuttle software. http://www.fastcompany.com/28121/they-write-right-stuff http://www.fastcompany.com/28121/they-write-right-stuff

FigBug 11y ago
And yet it still couldn't handle flying over new years: https://www.newscientist.com/article/dn10459-y2k-like-fears-create-shuttle-scheduling-crunch/ https://www.newscientist.com/article/dn10459-y2k-like-fears-...
- gsnedders 11y ago
  It probably could and in testing it could, they just decided not to find out whether it would really work properly when seven people's lives depended on it working. If you can practically avoid an edge-case you haven't ever relied on in decades before when people's lives depend on it, not risking it doesn't seem that crazy.
- chris_wot 11y ago
  Actually, they could but given the fact that the shuttle is not much different to strapping equipment and people to a gigantic bomb they seem to have decided that even though exhaustive testing found no issues a small change in the schedule was less risky.
nightski 11y ago
It isn't a practical solution for the majority of software out there. I also think that while their method works, it is pretty archaic. Looking to the future I hope we can find a way to achieve the level of results they do, without the ridiculous effort and cost.
- pron 11y ago
  > Looking to the future I hope we can find a way to achieve the level of results they do, without the ridiculous effort and cost. That is unlikely. For computational complexity theory reasons, writing correct software is extremely computationally expensive (regardless of whether or not the language is Turing complete). In fact, it is "the hardest problem in computer science", in the sense that any problem with bounded complexity can be efficiently reduced to software verification. Even verifying finite-state-machines (the simplest computational model) is PSPACE-hard. What we can do is find many ad hoc ways, each helping to some extent with some kinds of correctness properties.
  - nightski 11y ago
    Most software problems I encounter in the real world ARE of bounded complexity, and they can be reduced to software verification. But this is still a very tedious process and there are significant gains to be had by making this more accessible without having to solve the hardest problem in computer science.
    - pron 11y ago
      Certainly. It's just that there cannot be one (or a few) advances that would make writing correct programs generally easy. We can concentrate on domains (in the safety-critical embedded world this is almost a solved problem for some kinds of applications thanks to the invention of synchronous languages in the '80s, that make formal verification relatively efficient). We can also address some "internal" properties, like memory safety and transactions, that on the whole might make writing correct programs easier (though not provably correct).
- adrianN 11y ago

protomyth 11y ago

> Is there some reason to believe that with enough money software could be bug-free? NASA with the Space Shuttle software came pretty close. http://history.nasa.gov/computers/Ch4-5.html http://history.nasa.gov/computers/Ch4-5.html

kruczek 11y ago
In case of NASA, it's not only because of money though. It's because of a very rigorous process of designing and testing their software, sufficient time to follow this process, as well as writing a single product for a single customer. Of course money enables such process, but alone it is not sufficient.

marcosdumay 11y ago

Enough money and the goal of making software bug free can make it bug free. But enough money and the goal of making it infinitely flexible, having all the possible features, or the most perfect UX that a team can not decide on what it is will only make the software more bloated than it's reasonable, and fill it with bugs.

deleted 11y ago
[deleted]

panic 11y ago

I think "bug-free" software is a distraction. It's fine to make the occasional mistake. The real problem here is that nobody seems to take these mistakes seriously. Everyone seems to expect software to be occasionally broken, including the people writing it.

catnaroek 11y ago
Aren't your second and last sentences in conflict? How could we not expect software to be "occasionally" broken, if it's "fine" to make the "occasional" mistake? Of course, making mistakes is only human, but mistakes should never get past the build process (compilation, automated testing). Any mistake that does reflects an error in your design (not making your code amenable to verification) and/or your process (not capturing requirements in tests).
- panic 11y ago
  Yeah, using "occasionally" in both places drew a parallel that I didn't intend. We can expect people to make mistakes without accepting broken software. As you say, there are processes that can reduce the impact of mistakes on the final product. I think a culture of taking issues seriously is also important. Small mistakes are easy to make, but they're easy to fix if the organization has a good way for them to be reported and allows people to spend time fixing them.

forgotpwtomain 11y ago

> Developers are often guilty of just refactoring for no particularly good reason other than their personal sense of aesthetic, which can lead to endless (and destructive) refactoring. There are lots of good reasons to refactor - if indeed frivolous refactoring is more prevalent I would think this kind of opinion should be supported by a source/reference.

pmarreck 11y ago

> that with enough money software could be bug-free? According to empirical studies, practicing TDD leads to a 90% (yes, that number is correct) post-ship bug reduction at an upfront cost of 15-35% more development time. Which seems like a pretty good tradeoff, to me. (And I've experienced it firsthand.)

DomreiRoam 11y ago
Do you have any links on this studies?
- pmarreck 11y ago
  Here is the infamous Nagappan TDD paper from Microsoft Research http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.... Also discussed in this infoq article http://www.infoq.com/news/2009/03/TDD-Improves-Quality http://www.infoq.com/news/2009/03/TDD-Improves-Quality Here's someone's thesis paper on it, with data: http://www.nomachetejuggling.com/files/tdd_thesis.pdf http://www.nomachetejuggling.com/files/tdd_thesis.pdf There's also interesting discussions like this http://programmers.stackexchange.com/questions/206355/the-relative-cost-efficiency-of-acceptance-test-driven-development http://programmers.stackexchange.com/questions/206355/the-re... "it is my experience that the value proposition for TDD grows exponentially as the time and resources involved in a project grows linearly." This has also been my own experience. This person's comment also is interesting and has data http://programmers.stackexchange.com/a/210756 http://programmers.stackexchange.com/a/210756 Some of the above is empirical (read: scientific, no-bullshit) data. My opinion on it has grown to the point that I think TDD should literally be inseparable from programming, and the two together should simply be called, "programming." Lacking any unit tests whatsoever (TDD or otherwise) should be called, "taking stupid, extremely hazardous risks to save a little time, like reading your phone while driving" I've not found a programming task in at least 5 years that wasn't waaaay better-written when done via TDD. Some things, like IO, can be a challenge to unit-test, but that's why we have great ideas to solve that like Gary Bernhardt's awesome "Boundaries" talk https://www.youtube.com/watch?v=yTkzNHF6rMs https://www.youtube.com/watch?v=yTkzNHF6rMs

lmm 11y ago

> Is there some reason to believe that with enough money software could be bug-free? Yes. It's pretty easy to write provably correct software, just expensive. > Developers are often guilty of just refactoring for no particularly good reason other than their personal sense of aesthetic, which can lead to endless (and destructive) refactoring Not my experience, but even if so, if you require your software to be proven correct then it won't matter - any refactor that breaks it simply won't be accepted. > More money also makes people design lazy, so that instead of finding clever ways to reduce effort and improve uniformity, you just have everyone make their own forms. Um what? What does this have to do with anything?

majewsky 11y ago
Once you have provably correct software, the much harder problem is provably correct hardware. :)
- lmm 11y ago
  Shrug. We have provably validated diodes AIUI. If you can get provably correct basic components you can build up complex components using the same techniques as in software.
- hyc_symas 11y ago
  Good point. But choose the wrong hardware and you can never have provably correct software. E.g., the Intel x86 ISA makes all x86 processors impossible to prove correct. (there are 2^120 possible instruction encodings - the universe will die heat death before anyone could verify all of them in an implementation http://www.emulators.com/docs/nx06_rmw.htm http://www.emulators.com/docs/nx06_rmw.htm )