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

You are never taught how to build quality software

florianbellmann.com

Post reply on HN
Print view View original

181–190 of 500 posts

Re: You are never taught how to build quality software

#181

Post by groestl »

Xeamek wrote: post #140
groestl wrote: post #118

Earlier quoted context omitted.

> Running a program less then 100 times total, across all its user, is just very little for anything that could be considered commercial Running that kind of software for the central bank here. So kind of disputing your statement. > So I am simply excluding this category as an extremum. Which ignores the long tail. Great approach.

What software are you running that gets less then 100 usages before it gets retired? >Great aproach Unironically better, then trying to make prescriptions as broad and general as possible, because those usually are too generic to carry any actual value

Yearly reports. They can be buggy, can be off by millions, due to rounding errors. They can crash. They can run for days. Nobody cares enough to rewrite them, because regulation will change before that effort amortizes.

Also note that I wrote "code" originally, because there can be programs which are run very often, but certain code paths are not, so my statement applies even for some parts of popular software.

The image I think would be valuable for you to consider is a curve, where 20% of code has 80% of all executions, and 80% of code get's the rest. It makes sense to put in a lot of effort into writing the top 20%, but on any given day it is very likely you'll be working on the lower 80%.

Re: You are never taught how to build quality software

#182

Post by dgacmu »

cochne wrote: post #138
Gare wrote: post #108

Earlier quoted context omitted.

How about a formal proof? :) I jest, but that should be the gold standard for anything life-critical and good to have for mission-critical software. Alas, we're not there yet.

I never really got how proofs are supposed to solve this issue. I think that would just move the bugs from the code into the proof definition. Your code may do what the proof says, but how do you know what the proof says is what you actually want to happen?

Not really. Imagine the proof says: "in this protocol, when there are more than 0 participants, exactly one participant holds the lock at any time"

It might be wrong, but it's pretty easy to inspect and has a much higher chance of being right than your code does.

You then use proof refinement to eventually link this very high level statement down to the code implementing it.

That's the vision, at least, and it's sometimes possible to achieve it. See, for example, Ironfleet: https://www.microsoft.com/en-us/research/publication/ironfle...

Re: You are never taught how to build quality software

#183

Post by kevindamm »

topaz0 wrote: post #155
akhosravian wrote: post #137

Earlier quoted context omitted.

I’m not a CS academic or a mathematician, but don’t Godel’s incompleteness theorems preclude a formal proof of correctness?

No. There are plenty of things that can be proved, it's just that there exist true statements that cannot be proved.

That's closer, but still not quite right.

There are well-formed statements that can be proved but which assert that its godelized value represents a non-provable theorem.

Therefore, you must accept that it and its contradiction are both provable (leading to an inconsistent system), or not accept it and now there are provable theorems that cannot be expressed in the system.

Furthermore, that this can be constructed from anything with base arithmetic and induction over first-order logic (Gödel's original paper included how broadly it could be applied to basically every logical system).

Re: You are never taught how to build quality software

#184

Post by drewcoo »

ysofunny wrote: post #3

you cannot be taught what nobody knows how to do or maybe, them who know how to do this are just unable to spread this knowledge... something about how they think their private secret codes are the source of their wealth when in fact, it's merely the scheme by which they mantain an advantageous capacity to extract energy from them seeking to learn how to build quality software

> you cannot be taught what nobody knows how to do

It's worse than that. No one can agree what "quality" means.

Mostly, the word is used as a weapon.

The pointy end of the weapon is what management pokes you with whenever anything unexpected happens. Typically they do this instead of making sure that problems do not happen (a.k.a. "management").

The weapon's handle is sometimes flourished by process gatekeepers who insist on slowing everything down and asserting their self-worth. This is not good for throughput, anyone else's mood, or eventually even for the gatekeepers.

People usually refuse to talk about quality in terms of actual business metrics because if anything unexpected happens that's not covered by the metrics, there will be fault-finding. And the fingers pointed for wrong metrics are typically pointed at middle management.

Re: You are never taught how to build quality software

#185

Post by bluGill »

fidotron wrote: post #144
sanderjd wrote: post #124

Earlier quoted context omitted.

Yes, but that software is not bug-free. The claim was not "it's impossible to make software that does not exhibit bugs too a casually noticeable degree". People who know how the sausage is made will always know of a bunch of bugs that haven't been fixed exactly because they aren't impactful enough to be worth the effort required to fix them.

If it works within specs it is bug free. It doesn’t matter how it is made if it works within specs, which is one of the real unfortunate truths of software. The other is working out the correct specification is far harder than coding is. For example it is trivial to write a bug free program that multiplies an integer between 3 and 45 by two.

Most devices work within the spec 99.9% of the time, but that last .1% it is outside the spec. The exact % is different for different projects of course, but the idea is still there: no software operates according to spec 100% of the time.

Re: You are never taught how to build quality software

#186

Post by avgDev »

fidotron wrote: post #112
sanderjd wrote: post #92

Earlier quoted context omitted.

What proof is all around us?

The amount of software in everyday objects which runs without exhibiting bugs to such a degree we do not notice most of it even exists.

There are people PUTTING out fires nonstop in many apps we all use.

I have been writing code for almost a decade now, and still make errors. I don't believe anyone is capable of producing bug free software.

I have also seen plenty of bugs in apps and games. I don't think I have ever witnessed a major game patch that was bug free.

Re: You are never taught how to build quality software

#187

Post by hinkley »

bakul wrote: post #152
titzer wrote: post #117

We do teach these things, they are just not core CS topics, but rather in other areas, relegated to electives like a software engineering course. At CMU we have entire Master's program for software engineering and an entire PhD program (in my department). We teach exactly the kinds of things the blog post is about, and more. Software Engineering is a whole field, a whole discipline. I get that this is a blog post and…

Do SE classes teach debugging skills? I hope they do. So many times I have seen people try random things rather than follow a systematic approach.

I worked with programmers around my junior year and some of them were in classes I was in. I thought they were all playing one-upsmanship when I heard how little time they were spending on homework. 90 minutes, sometimes an hour.

I was a lot faster than my roommate, and after I turned in my homework I’d help him debug (not solve) his. Then I was helping other people. They really did not get debugging. Definitely felt like a missing class. But it helped me out with mentoring later on. When giving people the answer can get you expelled, you have to get pretty good at asking leading questions.

Then I got a real job, and within a semester I was down below 2 hours. We just needed more practice, and lots of it.

Re: You are never taught how to build quality software

#188

Post by ska »

titzer wrote: post #168
__loam wrote: post #149

Earlier quoted context omitted.

I took one of these kinds of classes in my masters program this year. They were totally obsessed with UML. It would be nice if these classes could move beyond dogma that is decades old.

CMU constantly reevaluates its MSE program with input from many different angles. I've participated here and I think we're trying hard to balance important foundational knowledge with practical skills of the day. I don't think we over-emphasize UML or any one particular silver bullet in our program.

To a first approximation, software developers don't have masters degrees. If you are thinking about changing how an industry does its work, focusing on graduate courses seems counterproductive.

Re: You are never taught how to build quality software

#189

Post by fidotron »

digging wrote: post #174
fidotron wrote: post #144

Earlier quoted context omitted.

If it works within specs it is bug free. It doesn’t matter how it is made if it works within specs, which is one of the real unfortunate truths of software. The other is working out the correct specification is far harder than coding is. For example it is trivial to write a bug free program that multiplies an integer between 3 and 45 by two.

> If it works within specs it is bug free. No, it's functional. If it has bugs, it's not bug-free. By definition.

What would it mean to be bug free then?

To quote a former marketing guy “it should work out what the user intends to do and do it”?

Re: You are never taught how to build quality software

#190

Post by hinkley »

__loam wrote: post #149
titzer wrote: post #117

We do teach these things, they are just not core CS topics, but rather in other areas, relegated to electives like a software engineering course. At CMU we have entire Master's program for software engineering and an entire PhD program (in my department). We teach exactly the kinds of things the blog post is about, and more. Software Engineering is a whole field, a whole discipline. I get that this is a blog post and…

I took one of these kinds of classes in my masters program this year. They were totally obsessed with UML. It would be nice if these classes could move beyond dogma that is decades old.

Wait. This year?

I haven’t touched UML for ten years.

Post reply on HN