Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The economics of software correctness

drmaciver.com

Post reply on HN
Print view View original

21–30 of 54 posts

Re: The economics of software correctness

#21

Post by seiji »

davidw wrote: post #17
seiji wrote: post #16

Earlier quoted context omitted.

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.

Re: The economics of software correctness

#22

Post by meatysnapper »

pm90 wrote: post #20
eCa wrote: post #19

Earlier quoted context omitted.

> People often underestimate the difficulties of getting a hack to work and overestimate how long doing something correctly will take. Yes. And sometimes one of those people is your boss.

Most of the times, I would say. Perhaps the biggest tragedy of Software Development today is how few managers actually do/have done enough software development to qualify managing those who do.

Management has two goals: 1) Make themselves look like they contribute value: Micro-manage projects, track time spent, etc. Even if there's nothing achieved, they can claim to be doing something and organizing meetings. 2) Swap out programmers like cogs in a machine. 3) There is no incentive to have good quality code because chances are everybody will be off the project in a year or so, so you take credit for the success and place the failure on the poor SOBs who have to maintain the system.

Re: The economics of software correctness

#23

Post by obastani »

shasta wrote: post #18
davidw wrote: post #6

Earlier quoted context omitted.

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 eco…

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

Re: The economics of software correctness

#24

Post by wellpast »

> If you want better software, make or find tools that reduce the effort of finding bugs. ... Better monitoring is another. Code review processes. Static analysis. Improved communication. There are many more.

I'm going to come out and suggest that even THESE are more expensive than most businesses need. I believe code review processes are insanely expensive for what they usually return (wrt bug costs).

Re: The economics of software correctness

#25

Post by crpatino »

amelius wrote: post #13
a3voices wrote: post #2

It's possible to write software with very few bugs if you're very experienced in the language/framework and software development in general, writing all the code yourself, and perfectly understand the requirements. Otherwise, good luck.

Sometimes, writing bug-free code isn't even sufficient; sometimes, one needs proof that it is bug-free. Then, your favorite language/framework will not help you much. You'll need strong verification tools, and a language and frameworks that are compatible with it.

While I won't deny this point, I think the industry at large would benefit quite a lot if we were able to agree on how to write probably bug-free code, even if empirically.

Reality is that within a group of 10, you might as well get 12 or more prescriptions of how to write quality software. About half of those prescriptions will be useless and at least one will be actively harmful, but the team will have a hard time to reach a consensus and tell which is which.

Actually, the people most likely to tell which is the obviously harmful prescription learn pretty fast to keep their mouths shut, because they are more likely to alienate their peers than to convince them. So, everybody knows that thousand-lines-long functions are bad, but nobody can tell exactly why besides the bland, non-threatening "style" argument.

Re: The economics of software correctness

#26

Post by shasta »

obastani wrote: post #23
shasta wrote: post #18

Earlier quoted context omitted.

> 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 eco…

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 sema…

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.

Re: The economics of software correctness

#27

Post by cyan_atrus »

meatysnapper wrote: post #22
pm90 wrote: post #20

Earlier quoted context omitted.

Most of the times, I would say. Perhaps the biggest tragedy of Software Development today is how few managers actually do/have done enough software development to qualify managing those who do.

Management has two goals: 1) Make themselves look like they contribute value: Micro-manage projects, track time spent, etc. Even if there's nothing achieved, they can claim to be doing something and organizing meetings. 2) Swap out programmers like cogs in a machine. 3) There is no incentive to have good quality code because chances are everybody will be off the project in a year or so, so you take credit for the suc…

i think you might be misunderstanding the point of managers..

Re: The economics of software correctness

#29

Post by swalsh »

hyperpallium wrote: post #28

What about reducing bugs through code reuse, in the form of libraries and frameworks? Because they have more users, more bugs have been found, reported and fixed. e.g. using standard libraries instead of writing your own.

code reuse is actually dangerous though. It's possible to use a library, have an expectation on how it will work, and then forget about that assumption, upgrade/fix something in the library, and proceed to break your assumption. It's a pretty common problem.

Often the time saved using a library is worth the small risk, but if we're talking about "how to write correct software" you'll want to be weary of code reuse.

Re: The economics of software correctness

#30

Post by methodover »

> You have probably never written a significant piece of correct software.

So true.

When we were hiring for a senior engineer position a few months ago, one applicant said he wrote "bug free code."

I laughed, sent it around on slack. We all chuckled at it. The applicant did not get a call.

Post reply on HN