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

Don't write bugs

teamten.com

Post reply on HN
Print view View original

21–30 of 113 posts

Re: Don't write bugs

#21

Post by jayd16 »

bombcar wrote: post #5

At first glance this may sound like advice for a baseball player - “don’t strike out” - but that’s exactly what good players do - they work at identifying the things that get them to strike out and try to minimize them. Tony Gwynn spent hours reviewing tapes of his at bats. Keeping a log of your mistakes and analyzing them is helpful in any number of things, including coding. Can you not write any bugs? Probably not.…

There are also techniques that allow for less mistakes without more effort.

You can say "try harder to not cut your hand off with the table saw" or you can get a push stick.

Re: Don't write bugs

#22

Post by carapace »

See the work of Margaret Hamilton, coiner of the term "software engineering" and developer of software for the Apollo mission.

> In 1976, Hamilton co-founded with Saydean Zeldin a company called Higher Order Software (HOS)[46] to further develop ideas about error prevention and fault tolerance emerging from their experience at MIT working on the Apollo program.

https://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist...

Crapped on by Dijkstra himself: https://www.cs.utexas.edu/users/EWD/ewd08xx/EWD852.PDF

Written up by James Martin (without proper attribution in my opinion) in "System design from provably correct constructs : the beginnings of true software engineering": https://archive.org/details/systemdesignfrom00mart/mode/2up

See also: https://en.wikipedia.org/wiki/Universal_Systems_Language

Re: Don't write bugs

#23

Post by matsemann »

Use tools that make it harder. Immutable datastructures, side effects constrained to a few places, good static typing etc.

Where I worked before we had 100k LoC Elm projects with virtually no bugs.

Now I'm working in a python/django codebase with probably thousands of small hidden bugs.

Re: Don't write bugs

#24

Post by dgb23 »

code_biologist wrote: post #11
bombcar wrote: post #5

At first glance this may sound like advice for a baseball player - “don’t strike out” - but that’s exactly what good players do - they work at identifying the things that get them to strike out and try to minimize them. Tony Gwynn spent hours reviewing tapes of his at bats. Keeping a log of your mistakes and analyzing them is helpful in any number of things, including coding. Can you not write any bugs? Probably not.…

It really annoys me that whenever I argue for "don't write bugs" as a quality practice, people immediately respond with all sorts of justifications why that's not possible. Of course it's not. But that doesn't mean we can't improve. We spend time and money on CI, linting systems, sprint retros — so the allergy to "think more carefully about what you wrote" surprises me.

There is no allergy. The advice given is as basic as it gets. That’s what people already have been doing for years and decades. It’s comically insufficient. what else can be done? How do we deal with the reality of mistakes?

Bug journals, code reviews, prioritizing fixes, tooling support, enough sleep and enough time! If you give me time, then I come up with more and more failure modes, checks, analysis, improved design, better tests. Who pays for that?

Re: Don't write bugs

#25

Post by saghm »

eeegnu wrote: post #12

When I do competitive programming, I celebrate the "one and done" moments where my first compile and test against the samples works, and then the submission too yields Answer Correct. Even for problems I'd consider hard I can semi reliably get this. But I find it much rarer for this to happen in my work, probably because I have to work with unfamiliar, often poorly (if that) documented code. But even with well writte…

Real-world problems tend also not to have existing comprehensive test suites that you can just instantly verify your implementation with. Writing the tests is not only something that usually has to be done by the same individual or team writing the implementation, but also can suffer from the same pitfalls as writing the implementation (incorrect assumptions, missed cases, simply doing the wrong thing, etc.)

Re: Don't write bugs

#26

Post by kuratkull »

This doesn't seem to take into account different codebases. At work I may have a decade old piece of code that has been partially rewritten multiple times and gets constant updates - it's also communicating with the outside world in many ways. The skill required to manage code like this without any bugs or even compiler errors is immense. But writing a 1000 line brand new project from scratch in a sane language is probably doable if you invest enough time - remember no compiler errors are permitted, so you have to write this in a basic text editor, then run the compiler and get 0 errors and bugfree software.

I can't stop picking on the 0 compiler errors thing. I could write brainf*ck and get 0 compiler errors, but no guarantees on the buginess of the code. I could also write Rust and the compiler throws errors when an assumption of mine was wrong, or I was trying to do something that the compiler does not yet support, or the codebase was large enough that all of it didn't fit into my mindmap. Not sure how to fully mitigate those causes.

Re: Don't write bugs

#27

Post by TrackerFF »

You have control over the code you write yourself, but you rarely have control over what code others write - even if your code review process is incredibly rigorous, there's rarely resources to check every single line of code that people write. And his becomes more infeasible, as size and complexity grows.

Furthermore, rarely can commercial products afford the luxury of such exhaustive protocols. Even slow moving, state-funded projects where safety is paramount, and thus - and the devs. basically have years to develop something, without the imminent pressure of showing a fully working product, you'll see bugs appear all over the place.

But I agree with others - there are definitive ways to minimize the problems from the start. Using right tools, enforce the right practices, etc. But with that said, bug-free coding becomes more unfeasible as MLOC, people involved, and new third party tools introduced increases.

Re: Don't write bugs

#28

Post by ukarim »

Probably it's true for type of bugs which could be catched by some kind of static analysis tooling (using uninitialized variables and etc.). You need just to remember some set of rules and never do "bad things". But what about bugs produced by unexpected inputs, system misconfigurations and so on

Re: Don't write bugs

#29

Post by jve »

kuratkull wrote: post #26

This doesn't seem to take into account different codebases. At work I may have a decade old piece of code that has been partially rewritten multiple times and gets constant updates - it's also communicating with the outside world in many ways. The skill required to manage code like this without any bugs or even compiler errors is immense. But writing a 1000 line brand new project from scratch in a sane language is pr…

Compile time errors are cheap and it would be silly to optimize for that. IDE just tells you: hey, this line, you forgot something. It is a few seconds to fix. It doesn't and CAN'T go to production. It doesn't need debugging. And, if 1 data point can tell something, it comes naturally - the more I code, the less (if any) compile time errors I get. But if I do, it takes seconds to fix them.

Of course IDE and intellisense goes a long way to prevent compile time errors - it just tells you on-the-fly how not to make a mistake.

Untyped languages could be another story, as "compile-less time" is actual runtime bug. But I don't know - I work primarily with C#.

Post reply on HN