Live data from Hacker News

Don't write bugs

teamten.com

51–60 of 113 posts

Re: Don't write bugs

#51

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.

One thing that helps me a lot is: fail fast.

You program must break when something is not right because shitty lasts forever.

Immutable objects are great but you need to validate them when you construct them and throw an exception when something is not right. And functions should return what you would expect.

For example, this:

  function GetEntitryById(int id):Entity
  {
      var entity = [action to get an entity];
      if(entity == null) {
        throw new Exception("Entity not found");
      }
      return entity;
  }
is better than:

  function GetEntitryById(int id):Entity?
  {
      var entity = [action to get an entity];
      return entity;
  }

Re: Don't write bugs

#52
post #43

I have a problem with this way of thinking. Yes, you can actually focus on not writing any bugs, but should you? We have limited attention and mental resources. If you're fixing your car, should you focus on not getting any oil on yourself? Yes, you take precautions but that should not be your main focus.

Your analogy has flaws. If you get oil on yourself, you didn't break anything in the car. If you fix your car but use a wrong part or install it improperly, that's a bug and that's on you for being careless.

Re: Don't write bugs

#53
post #46

When writing code you have a mental model of the machine, and the language and libraries. Back in the day those mental models could be close enough to reality that writing bug free code could be a choice. It would take time but you can essentially run the program in your head. This is an old timer, back when machines and abstractions were simpler. The post makes sense in that context, but today you can't have a compl…

You can get that same effect today, just work in the same stack with the same libraries for years and you will learn exactly how everything works. Just need a stack that doesn't do breaking changes that often. If programming worked like the more manual jobs like plumbing then you'd work 5 years on a stack before they'd call you proficient at it. But nowadays you work 2 years before changing jobs to another stack, and…

It's not just your tech stack in the narrow sense, your software also can't talk to anything that changes: no browser, no third party service. Systems are rarely that isolated anymore.

Re: Don't write bugs

#54

Earlier quoted context omitted.

The linked article literally says “write code that compiles successfully from the first time without bugs”.

I do have some issue with that one, because it kinda implies that compiling is a big, expensive and final job. But with current-day languages and tooling, you can effectively run trial compiles constantly while writing the code. The sooner you spot an issue, the sooner it's fixed and the less painful it is. I take the performance hit and prefer my editor to have syntax highlighting, syntax checking, linters and (at l…

It is about deliberate practice. Being able to write code that compiles successfully without needing to test against the compiler is mostly the same skill as writing code that does what you intend it to without need for debugging. However practicing writing code that compiles the first time is a ton easier than practicing writing code that has no other bugs the first time, so you go practice that. It isn't perfect, but it is low hanging fruit that takes a few days to learn so why not.

Or another perspective, the compiler throwing errors at you for your code implies that your intuitive mental model for the language isn't 100% accurate. If you write code the compiler accepts then you most likely have a near perfect understanding of how the language works.

Re: Don't write bugs

#55
Firstly, I stopped taking this article seriously at "modern language (Java)". Apart from that, "we can decide to not put bugs in the code" is the most non-sensical thing I've ever read. OK, sure, you can eventually flush some or most bugs out before your code goes in for proper testing from formally-trained QA people, but unless all you're writing is "Hello World" applications or walking skeletons then writing bug-free code is not possible, hence the existance of an entire industry that revolves around finding bugs. Just because YOU can't find any more bugs in your own code, that doesn't mean there aren't any bugs in the code, which is why QA people are trained to employ methodical test techniques. This is commonly known as the "Absence-Of-Errors Fallacy".

Secondly, there's this concept called "Independence Of Testing", which essentially states that the more independent the tester is from the code, the more likely they are to find defects. The opposite of that is also true, the less independend the tester is, e.g. if the tester is the developer, then the less likely they are to find defects in their own code. Read mode here (section 5.1.1): https://www.istqb.org/downloads/send/2-foundation-level-docu...

Lastly, this article is essentially saying that proper testing by QA people is useless, which not only I strongly disagree with but also is something that a terrible developer would say.

Re: Don't write bugs

#56

When writing code you have a mental model of the machine, and the language and libraries. Back in the day those mental models could be close enough to reality that writing bug free code could be a choice. It would take time but you can essentially run the program in your head. This is an old timer, back when machines and abstractions were simpler. The post makes sense in that context, but today you can't have a compl…

The kind of bugs I write these days are quite different from the ones I made decades ago. My mistakes these days are from high level misunderstandings, rather than low level ones.

Re: Don't write bugs

#57
post #51

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.

One thing that helps me a lot is: fail fast. You program must break when something is not right because shitty lasts forever. Immutable objects are great but you need to validate them when you construct them and throw an exception when something is not right. And functions should return what you would expect. For example, this: function GetEntitryById(int id):Entity { var entity = [action to get an entity]; if(entity…

I think that code example depends on the type system. In elm, the compiler forces you to handle both cases if you return a Maybe. In Java everything can be null and blow up which is bad. In Kotlin you have to handle the possible null, but it's a bit brittle when calling into Java code.

But yeah, better to fail fast. That's why I want tools to catch stuff as I write the code, not when I run it, as I cannot run all cases so then it won't hit until prod.

Re: Don't write bugs

#58
post #53
post #46

Earlier quoted context omitted.

You can get that same effect today, just work in the same stack with the same libraries for years and you will learn exactly how everything works. Just need a stack that doesn't do breaking changes that often. If programming worked like the more manual jobs like plumbing then you'd work 5 years on a stack before they'd call you proficient at it. But nowadays you work 2 years before changing jobs to another stack, and…

It's not just your tech stack in the narrow sense, your software also can't talk to anything that changes: no browser, no third party service. Systems are rarely that isolated anymore.

Ah, right, I haven't had a regular webdev job. But then that is because your job is to glue together different services rather than implement a complex chunk of code. Most of the jobs I've had were me implementing a lot of low level complex chunks or doing the architecture to make those chunks easy to write, for example when writing the runtime of a ML framework.

So it isn't that the time changed, the old jobs where you code still exists. But we added millions of glue code jobs on top of that, and that changed how people view software development. But it is field specific, even if webdev is the most common you can still work in any of the many other areas where the rules are different.

Edit: And yes, gluing together components is ridiculously hard. It is just hard in a different way, your job then becomes to learn about new things as quickly as possible so you can properly glue them together rather than trying to think about what code to write. That isn't easy at all.

Re: Don't write bugs

#59
post #25
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.)

The test suites in competitive programming is a crutch, you aren't supposed to rely on them. Using them to guide your solution is like using the same data to train and test your machine learning model, if you do that then there is no point in practicing.

Re: Don't write bugs

#60
>, so we practiced writing bug-free code. After two years of practicing, and after my previous two years of log-keeping, I was able to write substantial programs (thousands of lines) and run them without compile or run-time errors on the first try. [...] the exercise convinced me that bugs don’t creep into our code by themselves. We put them there, and we can decide to not put them there.

One logic flaw in that self-reported assessment is that us readers don't really know if his 1000-line programs were truly proven to be bug free. But we can still set that aside and entertain the idea that just deciding to not write bugs actually prevents bugs. Consider various disciplines:

- programming: Some search/sort code that had a hidden bug for 20+ years. Both computer experts Jon Bentley at Carnegie Mellon Uni and Joshua Bloch (Java expert) created the same bug: https://ai.googleblog.com/2006/06/extra-extra-read-all-about...

- mathematics: Andrew Wiles 1st attempt at proving Fermat's Last Theorem had a flaw that was discovered by his peer reviewers. And the authors for a SAT math exam unwittingly wrote a bug: https://youtu.be/kN3AOMrnEUs?t=2m05s

- laws : legislators write laws with attempts at precise wording but it still has unintended loopholes or perverse incentives they never foresaw

Did all those people "decide to write bugs" therefore they can decide not to? Of course not. You can reduce bugs by following some best practices (e.g. use well-tested encryption library instead of rolling your own, etc) but bugs will still happen no matter how much you "decide" against it.

Put another way, conscientious people have already decided to not write bugs but since we don't know how to achieve that objective, it doesn't solve the issue.

Post reply on HN