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

41–50 of 54 posts

Re: The economics of software correctness

#41

Post by ArkyBeagle »

shasta wrote: post #5
davidw wrote: post #3

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

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

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.

Re: The economics of software correctness

#43

Post by pm90 »

WalterBright wrote: post #36
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.

Part of the job as a software engineer is to inform your manager as to the tradeoffs and the correct solution. Especially if well paid. Surely, there are bosses who won't listen. But of the ones I've worked for, nearly all would listen to a reasonable explanation of how best to achieve the goals, and would approve recommendations from below. If you've got a track record of being right, that helps a lot :-)

I agree. And the managers I've worked with: I'm glad they were there so that I personally didn't have to navigate the company hierarchy. But I strongly feel that the managers who were in the past good software developers have a much better idea of how to be managers...those who weren't, I've noticed a misplaced desire to prove themselves, which has hurt me personally.

Re: The economics of software correctness

#44

Post by mreiland »

kybernetikos wrote: post #14

So this is all true, however it is surprising how often in development you find people spending more time and effort getting the 'pragmatic' hack to work acceptably than it would have taken to do it right. People often underestimate the difficulties of getting a hack to work and overestimate how long doing something correctly will take. Even with short time horizons.

I personally hate working with people who put things in terms of 'right' and 'wrong', or 'correct' and 'incorrect'.

I honestly believe the key to software development is good decision making. If you're thinking in terms of right and wrong, correct and incorrect, then you're not making decisions, you're simply doing the right thing over and over again. Only it may not be the OPTIMAL thing, or the smart thing, in any specific instance.

For example, who here really believes proponents of unit tests have never painted themselves into a corner? How did that happen? By making poor decisions.

Stop thinking in terms of right and wrong. Seriously. Sometimes unit tests are a good decision, sometimes they're not. Sometimes that hack is a good decision, and sometimes it isn't.

You make a decision on a case by case basis, not because it's right.

Re: The economics of software correctness

#45

Post by mreiland »

brightball wrote: post #12

Everything in development is a cost-benefit trade off. Despite it's speed limitations, Ruby remains an excellent language for development because of its focus on developer efficiency. You can produce feature complete systems in a short period of time at the expense of slightly higher hosting costs, which is significantly cheaper than labor costs. Monolith development is still much faster than microservice development…

I agree within reason. I believe there are certain things that must happen, even with a 'get it done' mentality or the subsequent gitrdone is not possible due to productivity issues.

Things like error detection and reporting in the system absolutely have to be useful. I've seen systems where that isn't the case, and it destroys productivity.

So I agree in general, but I think there are a few areas that you need to get right or you can't gitrdone effectively for very long.

Re: The economics of software correctness

#46

Post by zappo2938 »

danjayh wrote: post #40
zappo2938 wrote: post #37

Joel Spolsky published a blog post in 2000 named "Things You Should Never Do" ( http://www.joelonsoftware.com/articles/fog0000000069.html ) It's about why Microsoft with IE6 won the browser war against Netscape who made the single worst strategic mistake a software company can make by rewriting Netscape 6.0 throwing out all the code from Netscape 4. Netscape was working with extremely buggy and convoluted code in the…

Funny thing is, Microsoft did almost the same thing with Windows NT. However, unlike Netscape, they had the resources to keep iterating their old junk while they worked on the totally new version.

Spolsky mentions that Microsoft was going to rewrite Word for Windows and Mac with the same code base, but someone decided because at the time Word Perfect was a better product, they should skip that idea.

http://blogs.msdn.com/b/rick_schaut/archive/2004/02/26/80193...

Re: The economics of software correctness

#47

Post by DRMacIver »

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…

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

Re: The economics of software correctness

#48

Post by DRMacIver »

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.

Most libraries found in the wild are kinda crap, because as an industry we have a massive problem where most of our stuff is built on free labour that people have performed in their spare time to scratch their own itch.

Using libraries is still generally a good idea, but its effect on software correctness is a bit of a coin toss.

Re: The economics of software correctness

#49

Post by nine_k »

mreiland wrote: post #44
kybernetikos wrote: post #14

So this is all true, however it is surprising how often in development you find people spending more time and effort getting the 'pragmatic' hack to work acceptably than it would have taken to do it right. People often underestimate the difficulties of getting a hack to work and overestimate how long doing something correctly will take. Even with short time horizons.

I personally hate working with people who put things in terms of 'right' and 'wrong', or 'correct' and 'incorrect'. I honestly believe the key to software development is good decision making. If you're thinking in terms of right and wrong, correct and incorrect, then you're not making decisions, you're simply doing the right thing over and over again. Only it may not be the OPTIMAL thing, or the smart thing, in any s…

I like the idea of finding a good decision in the context of a current situation. I don't like the idea that terms like 'correct' and 'incorrect' should not be used. For some problems, there exist exactly correct solutions (like adding integers). The lack of a well-founded or at least well-known correct solution is what forces you to look for an optimal solution made of trade-offs.

Re: The economics of software correctness

#50

Post by hyperpallium »

DRMacIver wrote: post #48
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.

Most libraries found in the wild are kinda crap, because as an industry we have a massive problem where most of our stuff is built on free labour that people have performed in their spare time to scratch their own itch. Using libraries is still generally a good idea, but its effect on software correctness is a bit of a coin toss.

Yes, libraries and frameworks vary in quality. My e.g, was for "standard libraries", meaning those that come with the language, though I didn't emphasise this.

Another problem with libraries in the wild is that as they add features, they add bugs. If they don't add features, they lose popularity and don't get used. If they are commercial, they are less popular, and get fewer bug reports (and fewer eyeballs checking for closed source). People don't want to pay for correctness.

I think you're right: correctness is pretty far down the priority list. Good enough is good enough.

BTW: static types have correctness benefits, but dynamically typed languages are very popular - and when static types are used, it's for performance and documentation. Languages using static types for correctness (e.g. ML family and haskell) are not mainstream.

Post reply on HN