[bdamm]

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]

There is. See the space shuttle software.

http://www.fastcompany.com/28121/they-write-right-stuff

[nightski]

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.

[adrianN]

I work on safety critical systems. At least 80% of the work for building such a system is not critical for the actual quality of the product, but is necessary to satisfy compliance rules. Documentation of the development process is really extensive.

[pron]

> 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]

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]

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).

[FigBug]

And yet it still couldn't handle flying over new years: https://www.newscientist.com/article/dn10459-y2k-like-fears-...

[gsnedders]

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]

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.

[protomyth]

> 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

[kruczek]

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]

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.

[panic]

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]

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]

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.

[pmarreck]

> 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]

Do you have any links on this studies?

[pmarreck]

Here is the infamous Nagappan TDD paper from Microsoft Research

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

Here's someone's thesis paper on it, with data:

http://www.nomachetejuggling.com/files/tdd_thesis.pdf

There's also interesting discussions like this

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

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

[lmm]

> 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]

Once you have provably correct software, the much harder problem is provably correct hardware. :)

[hyc_symas]

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 )

[lmm]

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.

[forgotpwtomain]

> 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.