Live data from Hacker News

You should write "without bugs"

korshakov.com

61–70 of 91 posts

Re: You should write "without bugs"

#61
post #29
post #20

Earlier quoted context omitted.

> What they don't do, is waste time walking around looking for spare money that has been dropped. Because that would almost certainly be a waste of time. Why is it usually a waste of time? Because people rarely lose multiple bills of money, and if they do, our vision system is well equipped to spot the other bills quickly. The opposite is often true with software in my experience. When there is a bug, it's often beca…

Again, if you see a bug, fix it. If you are already in a section of code, read through all of it. And heck, if you are not running late on anything, feel free to start trying to re-architect parts that you think are off. If I'm just caught by a strawman at the start of the essay, apologies on that. I legit don't know anyone that casually encourages bugs as long as you have features. Tolerances are a thing, but so is…

About 30 years ago, there was this wonderful book, called Writing Solid Code[0]. Reading it, was a watershed, in my personal development.

It has many techniques described, that have since become Canon, and a number that have not aged so well.

One that is probably impractical, these days, is Step Through Your Code. He recommends stepping through every line of your code in a symbolic debugger, making sure that the code flow is what you expect, and the app state is appropriate.

Every now and then, I can do it. Often, when I’m already there, for something else. It really does work.

[0] https://writingsolidcode.com/

Re: You should write "without bugs"

#62
post #35

In grad school I took a formal methods class where we proved properties about programs that completely changed how I think about bugs. The main things I took from the class were 1. Correctness of a program is distinct from its performance. 2. Program correctness can be proven. 3. Optimizing for performance often makes it harder to prove correctness. I do not actually use formal methods in my work as a developer, but…

> Program correctness can be proven.

It can be proven, in broadly the same sense as all of the atoms in your body can simultaneously "decide" to exist an inch to the right due to quantum field theory.

It is not practical to prove correctness for the vast majority of programs, and there are programs that are demonstrably incorrect, cannot be made correct, and yet are useful and still function anyway (e.g., closing TCP connections cannot be done "correctly").

Re: You should write "without bugs"

#63
post #17

Earlier quoted context omitted.

> the authors point is that a little bit of extra thought and work can make a lot of difference to quality Care to bring home the thesis on how that’s actually really insightful?

The author makes the insightful observation that they write non-buggy code by being careful, in contrast to the vast majority of developers who write code full of bugs. Being careful is left to the reader, but it should be easy. /s

Author makes insightful observation that once you start paying attention deliberately - after some time you won’t have to be deliberately careful because you will be careful by default.

There are devs who don’t pay attention and devs who pay too much attention to context of the change they are implementing. I think author also outlined which things one might pay attention to so they would be considered careful.

Re: You should write "without bugs"

#64
post #35

In grad school I took a formal methods class where we proved properties about programs that completely changed how I think about bugs. The main things I took from the class were 1. Correctness of a program is distinct from its performance. 2. Program correctness can be proven. 3. Optimizing for performance often makes it harder to prove correctness. I do not actually use formal methods in my work as a developer, but…

> Program correctness can be proven. It can be proven, in broadly the same sense as all of the atoms in your body can simultaneously "decide" to exist an inch to the right due to quantum field theory. It is not practical to prove correctness for the vast majority of programs, and there are programs that are demonstrably incorrect, cannot be made correct, and yet are useful and still function anyway (e.g., closing TCP…

> It is not practical to prove correctness for the vast majority of programs,

That is the excuse i hear a lot from software developers, when everything they do is to test the expected behaviour of a program, without any edge case.

And this is also the reason why iMessage and WhatsUp are full of one click exploits.

Re: You should write "without bugs"

#65
post #35

In grad school I took a formal methods class where we proved properties about programs that completely changed how I think about bugs. The main things I took from the class were 1. Correctness of a program is distinct from its performance. 2. Program correctness can be proven. 3. Optimizing for performance often makes it harder to prove correctness. I do not actually use formal methods in my work as a developer, but…

Correctness is also distinct from applicability/usefulness. A program that lacks some important edge cases is marginally more useful than a program that takes impractical amount of time for most inputs. So "Correctness of a program is distinct from its performance" doesn't imply "performance is optional".

Re: You should write "without bugs"

#66

I clicked on this because of the crazy title but its actually a really inisghtful article, e.g. "Conversely, there are people with commitment issues; they want to experiment non-stop and thus have no faith in robustness." ... like there's this belief that bugs will just happen anyway so why worry about them. But the authors point is that a little bit of extra thought and work can make a lot of difference to quality.

I think there's always argument that you don't know what you don't know. How much thought do you put on writing code with out bugs. Bug could be caused by the business logic, the language internals, the runtime environment internal and variation. I think what people often ignore writing piece of software is an iterative process, you build, deploy and learn from the operation and you fix and repeat. If you keep thinki…

> I think what people often ignore writing piece of software is an iterative process, you build, deploy and learn from the operation and you fix and repeat.

I presume you didn't use any Microsoft operating system (or program). /s

Re: You should write "without bugs"

#67
post #41

Writing code with fewer bugs is a function of experience. But, the reason is not entirely what you would think it is. Sure, a lot of it is anticipating problems previously experienced, and writing code that handles problems, or entire classes of problems, previously encountered. However, with more experience comes a better understanding of the general metastructure of code, and therefore an ability to hold more code…

Experience has taught me to test. A lot. I always find bugs, when I test, no matter how "perfect" I think my code should be. Also, I find that a lot of monkey testing is important. AI could be very beneficial, here. I anticipate the development of "AI Chaos Monkeys." https://littlegreenviper.com/various/testing-harness-vs-unit...

> Also, I find that a lot of monkey testing is important. AI could be very beneficial, here. I anticipate the development of "AI Chaos Monkeys."

Well, you just made me realise that there is still a use for those LLMs beside generating propaganda. The problem, i guess will be, that nobody will be willing to spend time on those bug reports.

Re: You should write "without bugs"

#68
post #35

In grad school I took a formal methods class where we proved properties about programs that completely changed how I think about bugs. The main things I took from the class were 1. Correctness of a program is distinct from its performance. 2. Program correctness can be proven. 3. Optimizing for performance often makes it harder to prove correctness. I do not actually use formal methods in my work as a developer, but…

When you convince yourself of the program correctness, are you using techniques from the class?

Any advice on reasoning about correctness?

Re: You should write "without bugs"

#69
post #64

Earlier quoted context omitted.

> Program correctness can be proven. It can be proven, in broadly the same sense as all of the atoms in your body can simultaneously "decide" to exist an inch to the right due to quantum field theory. It is not practical to prove correctness for the vast majority of programs, and there are programs that are demonstrably incorrect, cannot be made correct, and yet are useful and still function anyway (e.g., closing TCP…

> It is not practical to prove correctness for the vast majority of programs, That is the excuse i hear a lot from software developers, when everything they do is to test the expected behaviour of a program, without any edge case. And this is also the reason why iMessage and WhatsUp are full of one click exploits.

The comment you were replying to is about formal proofs of correctness, probably using tools like Rocq (formerly Coq) and TLA+.

These tools can take an extreme amount of time to use and require specialised skillsets that are difficult to hire for. They go far beyond standard software engineering practices like unit and E2E testing. It is genuinely, seriously not practical to verify the average startup's SaaS web app with TLA+; you'd go bankrupt.

Someone who's used them more than me might be able to comment on exactly how hard it would be, but I felt it was unfair to you not to explain.

Re: You should write "without bugs"

#70

If you actually want to write software without bugs: Assume that your code will have bugs no matter how good you are. Correct for that by making careful architecture decisions and extensively test the product yourself. There’s no silver bullet. If you put in enough time and make some good decisions, you can earn a reputation for writing relatively few bugs.

Yup. When I test, I always find bugs. Never fails. Watching this posting dive down from the HN front page has been interesting (and expected).

Hmm… Looks like it was “second chanced,” but it’s still struggling to stay relevant. Hasn’t really been shown much love.

It’s rather discouraging to see how discussions of Quality Development are treated, hereabouts.

Quality seems to be heresy.

Post reply on HN