The economics of software correctness • Hacker News Board

Re: The economics of software correctness

#11

Post by AnimalMuppet » Mon, Oct 05, 2015, 8:25 PM UTC

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.

It's even better if you're working with others who all are "very experienced in the language/framework and software development in general, and perfectly understand the requirements" - at least if you all communicate well with each other. Code reviews and people to bounce ideas off of reduce bugs, they don't add them.

Re: The economics of software correctness

#12

Post by brightball » Mon, Oct 05, 2015, 8:54 PM UTC

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 even though microservice development is the better long term option by far.

It's all tradeoffs. I'm an architecture nut and for years I really wanted nothing more than to design the ultimate perfectly scalable and secure system but unless you're at a virtually competition free enterprise, like a telecom or an insurance company the time or budget to do so probably doesn't exist.

I've gone from "get it done" to "do it perfect" back to "get it done and avoid obvious problem starters". The reality is just that "get it done" wins the business case almost every single time.

Re: The economics of software correctness

#13

Post by amelius » Mon, Oct 05, 2015, 9:04 PM UTC

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.

Re: The economics of software correctness

#14

Post by kybernetikos » Mon, Oct 05, 2015, 9:12 PM UTC

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.

Re: The economics of software correctness

#15

Post by davidw » Mon, Oct 05, 2015, 9:19 PM UTC

seiji wrote: post #10

shasta wrote: post #5

Earlier quoted context omitted.

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

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.

Re: The economics of software correctness

#16

Post by seiji » Mon, Oct 05, 2015, 9:30 PM UTC

davidw wrote: post #15

seiji wrote: post #10

Earlier quoted context omitted.

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.

Re: The economics of software correctness

#17

Post by davidw » Mon, Oct 05, 2015, 9:42 PM UTC

seiji wrote: post #16

davidw wrote: post #15

Earlier quoted context omitted.

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

Re: The economics of software correctness

#18

Post by shasta » Mon, Oct 05, 2015, 10:01 PM UTC

davidw wrote: post #6

shasta wrote: post #5

Earlier quoted context omitted.

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.

Re: The economics of software correctness

#19

Post by eCa » Mon, Oct 05, 2015, 10:07 PM UTC

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.

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

Re: The economics of software correctness

#20

Post by pm90 » Mon, Oct 05, 2015, 10:21 PM UTC

eCa wrote: post #19

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.

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