Hacker News Reader

Comment by davidw | Hacker News Reader

"The problem is not that we don’t know how to write correct software. The problem is that correct software is too expensive."

That's something I've been saying for a while. It's all about the economics of the situation, rather than the impossibility if it.

Naturally, there are also improvements here and there that decrease bugs without increasing efforts, and those are worth looking for.

View on HN

But in a practical sense, the problem is that we don't know how to write correct software.

Actually, we do have some pretty good ideas about how to do it. That was covered in the article.

> Better monitoring is another. Code review processes. Static analysis. Improved communication. There are many more.

Did you mean this? Or NASA's process? Because I wouldn't characterize any of the above as "good ideas about how to [build correct software]".

Reviewing some of your other comments, I think we fundamentally disagree about how close we are to optimal software development practices. Discussing this in economic terms is like discussing the economic reasons that Columbus didn't go to the moon.

I don't think that's a fair analogy. At this point, I believe we have pretty good ideas that make it possible to write correct software. Most impressively, there has been progress on creating a completely verified C compiler named CompCert: http://compcert.inria.fr/. This really means "completely verified"---they formalized the semantics both of C and of assembly, and used an automated theorem to prove that the semantics of the generated assembly are the same as the semantics of the source code.

Of course, building (and verifying) CompCert took something like 10 years, so it's certainly not a feasible way to write software yet. Maybe a better analogy would be around the invention of the first airplane---we have a long way to go before everyone's flying in a jumbo jet :)

Analogies are like shopping carts; you can only push them so far before they begin to make an annoying high pitched noise. Your analogy probably works better in the ways that you've explained, though.

> I don't think that's a fair analogy. At this point, I believe we have pretty good ideas that make it possible to write correct software. Most impressively, there has been progress on creating a completely verified C compiler named CompCert: http://compcert.inria.fr/. This really means "completely verified"---they formalized the semantics both of C and of assembly, and used an automated theorem to prove that the semantics of the generated assembly are the same as the semantics of the source code.

Note that Compcert has had bugs found in it too. Compcert has a verified core, but it's not a fully verified piece of software.

It's still a lot closer to bug free than almost any other software out there.

Yes, I was referring to the verified parts. To the best of my knowledge, these are bug free -- I believe the bugs were found in an unverified portion of the front-end (which I think was subsequently verified). I think the technique works in principle; it's just very, very expensive.

It's mostly based on the skill and experience of the developer. Of course there is probably some asymptote in the quality and delivery time that is impossible to surpass, like the 3 minute mile. Human brains are not without limits and we didn't evolve to write software.

It's not at all about developer skill. It's about methods and process.

Ok, you don't want to have a bunch of total bozo developers, or the time to get anything useful done will stretch out to infinity, but still, it's not about just 'being good'.

Well that's part of it. You need to have the experience to know which methods and processes give you the most value and quality for the time invested. There's many skill sets involved and knowing good processes is just one.

In my own experience. It is about skills. But if you don't have the skills you need more methods and process. The less skilled is your team, the more processes you need.

I think that's going down the wrong path: you can get "pretty good" software if you get the best people and just let them work on it. But it'll still have bugs. You need more process and stuff like verifiable software and all that kind of overhead to really start getting close to bug free.

We know how to do a lot of things well, but when all our tools are made by hobbyist hackers creating out of love of fun instead of love of sustainability (or worse, short term hacks for love of profit), we end up with the mess we have now.

A big point of the article is that what we have now is 'good enough' for most people, since they're not paying for more. If they were paying a bunch more, they'd get better stuff. But they don't want to. So the hand-wringing and finger pointing is useless: it's best to figure out how to get the most from what we do have.

If you really want to work on super high quality stuff, there are fields where that is valuable.

Well, our base tools are crap.

C is awful. Linux is awful. Docker "containers" are awful (i.e. fancy branding around cgroups; no actual 'container' at all unlike solaris zones which did everything properly 10 years ago plus Crossbow networking 5 years ago).

We keep using (and inventing) quick hacks promoted by braggadocious personalities instead of stable infrastructure or proper tooling.

The article is attempting to explain the economics of why that is so. It's a pretty important thing to understand.

Other pieces of the economic puzzle are things like network effects and lock in. I highly recommend this book: http://amzn.to/1FTa7ib

Thanks for the pointers. Looks fancy. I'll check it out.

The problem is better stated that we're not that interested in it. If we were interested in it, we'd know how.

I've released a couple of things that were tested to exhaustion, so far as anyone knows. One advantage of the event-driven approach is that you can do that.

Reply on news.ycombinator.com