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

441–450 of 500 posts

Re: You are never taught how to build quality software

#441

Post by randomdata »

zerkten wrote: post #68
randomdata wrote: post #47

Earlier quoted context omitted.

> But the goal is “better, always better, what can I do better?” Is that not the case in software? The incentive to improve may not be quite as strong as in aviation (crashing software isn't quite the same as crashing airplanes), but it is still pretty strong. Life is very miserable in software when quality isn't present.

What happens when you work under a group of people who are satisfied at stage one of project X? You know you can iterate to get two stages further, but they want you to work on projects Y and Z. This is a very common situation where you, or even the whole development team has very little control. Of course, management should be supportive of quality improvements, but their reality is either one where they are under g…

> What happens when you work under a group of people who are satisfied at stage one of project X?

No doubt the same as when the members of your garage band are happy to stay in the garage while you have your sights set on the main stage. You either suck it up and live in the misery, or you get better on your own time and leverage those improvements in the quality of your performance to move into a better position where quality is valued.

Re: You are never taught how to build quality software

#442

Post by sanderjd »

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.

As you alluded, in practice no specs fully specify a truly bug free implementation. If you want to consider bugs that are within the specification as being bugs in the spec rather than bugs in the implementation, fine, but in my view that is a distinction without a difference.

(Personally, I think code is itself more analogous to the specification artifacts of other professions - eg. blueprints - and the process of creating the machine code of what is analogous to construction / manufacturing something to those specs.)

And even having said that, even the vast majority "bug free" software that nearly always appears to be operating "within spec" will have corner cases that are expressed in very rare situations.

But none of this is an argument for nihilism about quality! It is just not the right expectation going into a career in software that you'll be able to make things that are truly perfect. I have seen many people struggle with that expectation mismatch and get lost down rabbit holes of analysis paralysis and overengineering because of it.

Re: You are never taught how to build quality software

#443

Post by marcosdumay »

randomdata wrote: post #430
marcosdumay wrote: post #9

Earlier quoted context omitted.

> Is there any human activity where quality is an attribute successfully taught? Every industrial practice. On the other hand, the title just means that programming is not an industrial practice. What should be obvious to anybody that looked, but some people insist on not seeing it.

What industrial practice isn't guided by carefully designed machines that remove the human variability?

You probably meant "that remove some human variability".

Machine handling requires a lot of training and a lot of well thought out procedures.

Re: You are never taught how to build quality software

#444

Post by mdaniel »

Xeamek wrote: post #402
mdaniel wrote: post #334

Earlier quoted context omitted.

I offer, again, my JetBrains GrammarKit counterpoint from the last time that assertion came up https://news.ycombinator.com/item?id=38192427 > >>> I consider the JetBrains parsing system to be world class and they seem to hand-write very few (instead building on this system: https://github.com/JetBrains/Grammar-Kit#readme ) - https://github.com/JetBrains/intellij-community/blob/idea/23... (the parser I'll concede, as…

To be fair though, jetbrains use case is fairly unique, as they basically want to implement parsing for as many languages as possible, all while doing it in a verry structured and consistent way, with having many other parts of their infrastructure being dependent on that parsing API. I think it's fair to say that those requirements are outside of the norm

I think that's a fine observation, but I'll also add that since their cases are almost always consumed in an editor context, they need them to be performant as well as have strong support for error recovery, since (in my mental model) the editor spends 90% of its time in a bad state. If I understand tree-sitter correctly, those are some of its goals, too, for the same reason

Re: You are never taught how to build quality software

#445

Post by bakul »

GuB-42 wrote: post #408
bakul wrote: post #152

Earlier quoted context omitted.

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.

But debugging is about "trying out random things". You can call it a Monte-Carlo tree search is you want to sound smart. And I don't feel is not something that is worth teaching in universities, because it is 90% experience and for me, the point of universities is not to replace experience, just give enough to students so that they are not completely clueless for their first job, the rest will come naturally. What un…

The "Monte-Carlo tree search" space is usually far too large for this to work well!

It is true that initially you may not know where the bug is but you have to collect more evidence if possible, see if you can always cause the bug to manifest itself by some tests, explore it further, the goal being to form a hypothesis as to what the cause may be. Then you test the hypothesis, and if the test fails then you form another hypothesis. If the test succeeds, you refine the hypothesis until you find what is going wrong.

Such hypotheses are not formed randomly. You learn more about what may be the problem by varying external conditions or reading the code or single stepping or setting breakpoints and examining program state, by adding printfs etc. You can also use any help the compiler gives you, or use techniques like binary search through commits to narrow down the amount of code you have to explore. The goal is to form a mental model of the program fragment around where the code might be so that you can reason about how things are going wrong.

Another thing to note is you make the smallest possible change to test a hypothesis, at least if the bug is timing or a concurrency related. Some changes may change timing sufficiently that the bug hides. If the symptom disappears, it doesn't mean you solved the problem -- you must understand why and understand if the symptom disappeared or the bug get fixed. In one case as I fixed secondary bugs, the system stayed up longer and longer. But these are like accessories to the real murderer. You have to stay on the trail until you nail the real killer!

Another way of looking at this: a crime has been committed and since you don't know who the culprit is or where you may find evidence, you disturb the crime scene as little as possible, and restore things in case you have to move something.

But this is not usually what happens. People change things around without clear thinking -- change some code just because they don't like it or they think it can be improved or simplified -- and the symptom disappears and they declare success. Or they form a hypothesis, assume it is right and proceed to make the "fix" and if that doesn't work, they make another similar leap of logic. Or they fix a secondary issue, not the root cause so that the same bug will manifest again in a different place.

Re: You are never taught how to build quality software

#446

Post by ch4s3 »

chiefalchemist wrote: post #321
ch4s3 wrote: post #256

Earlier quoted context omitted.

Hum, interesting perspective. I did 95% of a masters in CS before leaving to do a startup and while I can see the value of parser generators, there are a LOT of times when it is appropriate, useful, and more performant to write your own simple parser. It's often in my opinion the right thing to to first for simple cases. Clearly you should test it and consider functional requirements, but a stringy protocol with clea…

My impression is the gist is: When you think like an engineer, your focus is on problem solving, and using the appropriate tool(s) to do that. On the other hand, typical developers instinct is to code, code, code; at least based on my experience.

I don’t know if you’re trying to be rude, but this comes across as quite disrespectful.

Parser tools are indeed very powerful, but those abstractions carry tradeoffs that any “engineer” will consider.

Re: You are never taught how to build quality software

#447

Post by ch4s3 »

valenterry wrote: post #361
ch4s3 wrote: post #256

Earlier quoted context omitted.

Hum, interesting perspective. I did 95% of a masters in CS before leaving to do a startup and while I can see the value of parser generators, there are a LOT of times when it is appropriate, useful, and more performant to write your own simple parser. It's often in my opinion the right thing to to first for simple cases. Clearly you should test it and consider functional requirements, but a stringy protocol with clea…

I've never had it once in my career where using a parser generator wasn't better. Given that it's an in-language parser generator and not some meta-language monstrum like ANTLR. Maybe when writing your own programming language, own complicated data format or low communication protocoll while requiring extreme performance. But that seems to be super rare, at least in my area of profession.

I’ve had a very different experience. I can think of three occasions where I was able compare a hand written parser with something built using a parser generator or similar tool. In two of those cases, the hand written code was far easier to read and modify. This kind of code can also be easier to test.

Parser generators aren’t a free lunch and they vary considerably in quality.

Re: You are never taught how to build quality software

#448

Post by randomdata »

marcosdumay wrote: post #443
randomdata wrote: post #430

Earlier quoted context omitted.

What industrial practice isn't guided by carefully designed machines that remove the human variability?

You probably meant "that remove some human variability". Machine handling requires a lot of training and a lot of well thought out procedures.

And, most importantly, practice, practice, practice.

Re: You are never taught how to build quality software

#450

Post by sanderjd »

fidotron wrote: post #213
bluGill wrote: post #185

Earlier quoted context omitted.

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.

It does though. My example of adding two ints within a known finite range would operate to spec 100% of the time. You would have to introduce things like tolerance to hardware failure, but that is outside the spec of the software as stated.

Yes, but that's not real software.
Post reply on HN