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

91–100 of 113 posts

Re: Don't write bugs

#91

Post by thomascgalvin »

ryandrake wrote: post #84
pizlonator wrote: post #80

This is so funny. I can’t even. It’s true that you can write code that has no bugs that would be relevant in a programming contest. And that you can avoid the kinds of bugs that you’d find if you read your code 2-3 times. But if you write code that has to live for a long time, on a lot of devices, used by a lot of people, and that gets attacked by adversaries, then you really start to appreciate the inevitability of…

I think that's pretty fatalistic. The way I see it, bugs are not inevitable, but a consequence of (often good) decisions that get made in a software project. Decisions by developers, managers, product owners, marketers lead to them. Decisions to adhere to a deadline, to add another feature, to focus on this and not that, to learn or not learn from previous mistakes. The fact that these decisions tend to be made in a…

> The way I see it, bugs are not inevitable

There's a lot of argument over just how many "facts" the average person can keep in their mind at any one time, but let's be extraordinarily generous and say you can keep track of twenty "things", simultaneously.

Now, let's say you need to connect to a URL, download an RSS file, process it, turn it into a list of podcasts, determine which ones haven't already been listened to or downloaded, and download them. Metadata will be persisted in SQLite. Binaries will be written to the file system. You need to do this on MacOS, iOS, Android, Windows, and Linux.

It would be trivial to come up with more than twenty "things" you need to keep track of to do this. The subtle differences between network connections on the various host OSes, the differences in the file system. Are you on SQLite 2 or 3, and what does that mean for the concurrency mechanism? What happens if the user asks you to update the list while you're in the middle of downloading an episode? What do you do when an episode appears in your database, but not the RSS feed? What happens when your download fails? What happens if the user shuts off their phone in the middle of a download?

Software is hard because software is massively, massively complex. There are a thousand things happening under the covers. Every single line of code we write is likely to have side effects, and we usually aren't even going to be sure what those side effects are.

That's why bugs are inevitable. It isn't out of laziness, though lazy coders do write buggier code. It's because we have built a teetering Jenga tower of abstractions, and we keep piling on top of it. This makes us much more productive, in the long run, but it also makes "perfect" code essentially impossible.

Re: Don't write bugs

#92

Post by etblg »

jerf wrote: post #83
larrik wrote: post #82

Earlier quoted context omitted.

> if my API had a different input type for each country's tax ID Like you just add a new field for every country you support? I can imagine quite a few ways to break that. For instance, my system has users from USA and CA, and I just send you everything in the SSN field, because I didn't consider the CA users when I wrote it. The simple way would have just worked, but now the API is broken for me.

No, add a new type. If your SSN is of type "USSocialSecurity" and the canadian system needs "CanadianTaxID" (sorry, I don't know what it is) then the API will not accept the wrong thing in the wrong place. "But what if I label it incorrectly and send it along?" Then that's a bug in your code. No amount of my API design can prevent bugs in your code. All my API can do is not help you write bugs in your code. I can't s…

In Canada it's a SIN!

(Social Insurance Number)

Re: Don't write bugs

#93

Post by merkle »

Just saying "Don't write bugs" sounds a little but naive for me. I never saw someone that could achieve that task and nothing makes me believe that the author's statement might be remotely truthful.

My two cents: I can only write average software by writing tests simultaneously or right after writing the functionality. Reading the code thousands times without writing tests would just not work for me.

Re: Don't write bugs

#94

Post by ensiferum »

tdrdt wrote: post #51
matsemann wrote: post #23

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…

If it's a bug, i.e a error made by the programmer then assert and dump core.

Re: Don't write bugs

#95

Post by agentultra »

A friend of mine was supervising students while doing his PhD. He gave them a task to write an implementation of binary search that contained no errors. He received twelve submissions.

If I am recalling the story right, he verified each submission in a proof assistant. Eight of the submissions contained errors. These were not first-year, green students writing binary search for the first time.

Empirical studies, few as they are, aren't forgiving either. It turns out that memory management, life times, concurrency, and ordering of computational effects are simply hard for the human mind to comprehend on the scale of non-trivial programs. We need better tools for thinking to help us manage. Otherwise we lean on heuristics and practices and assume some level of tolerance for errors to be made.

Don't write bugs, is not going to be very forgiving when even the most well-trained among us will, eventually, introduce an error into a program.

Re: Don't write bugs

#96

Post by lamontcg »

gwbas1c wrote: post #77

Superficially, "Don't write bugs" really only translates to "don't be sloppy, if you're aware of ways that your code will fail in edge cases, handle those edge cases. Develop techniques and habits that will avoid bugs, like better encapsulation." However, "Don't write bugs" is a joke for a seasoned programmer who's had to work with political constraints. Bugs often arise from major design flaws that can't be fixed in…

"Impractical to fix" can also mean writing an awful lot of complicated code to work around edge conditions that may never arise in reality. And the cost of writing that complicated code may result in additional bugs you didn't foresee due to the law of unintended consequences.

It becomes a tradeoff between the bug that you think you're smart enough to see but which may never happen, and the bugs that you're not able to see right now.

And I've definitely been on the wrong side of that equation and dealt with overly complicated code considering edge cases that were not useful, which caused complicated but practical bugs which affected many customers -- and I wound up replacing the overly thought out code with simpler code that was understandable and the "bug" I reintroduced never affected anyone AFAIK years later.

I've also been on the right side of that equation and picked simpler approaches and never had the overly complicated edge conditions that I could "see" in the code actually crop up and affect anything.

It isn't just political, sometimes you really can just technically outsmart yourself.

Plus there's the issue of if design decisions that are 10 years old should be refactored at the cost of introducing breaking changes and pain on everyone using your software. Sometimes you wind up writing some less-robust-than-ideal code which is due to those kinds of foundational issues. And the existence of a single difficult to fix bug is generally not sufficient to restort to blowing up your entire world and starting over again.

Re: Don't write bugs

#97

Post by [deleted] »

larrik wrote: post #82
mabbo wrote: post #74

Aftee a decade as a professional developer, the key practice I've found that makes all the difference is this: make it very difficult for someone using my code to use it wrong. Because no matter how well I write my code, I'm just one developer in a much larger system. An example: imagine I have an API that takes in a users tax id. In the US, let's presume that's an SSN. In Canada, a SIN. In Brazil, a CPF/CNPJ, and so…

> if my API had a different input type for each country's tax ID Like you just add a new field for every country you support? I can imagine quite a few ways to break that. For instance, my system has users from USA and CA, and I just send you everything in the SSN field, because I didn't consider the CA users when I wrote it. The simple way would have just worked, but now the API is broken for me.

[deleted]

Re: Don't write bugs

#98

Post by jfrunyon »

mabbo wrote: post #74

Aftee a decade as a professional developer, the key practice I've found that makes all the difference is this: make it very difficult for someone using my code to use it wrong. Because no matter how well I write my code, I'm just one developer in a much larger system. An example: imagine I have an API that takes in a users tax id. In the US, let's presume that's an SSN. In Canada, a SIN. In Brazil, a CPF/CNPJ, and so…

> On the other hand, if my API had a different input type for each country's tax ID,

Then you've significantly increased the work (and opportunity for bugs) required of a downstream programmer, and also made it significantly more likely that they won't support all countries, and of course they could also still send the wrong type...

Re: Don't write bugs

#99

Post by Viliam1234 »

Cthulhu_ wrote: post #36
hellohntoday wrote: post #35

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…

But we HAVE simplified. I can now type 'fetch this data matching these conditions sorted by this' and be confident about not having any bugs in my code, while underneath there's millions of lines and decades of other people's work and solved bugs being run. "Back in the day" they would spend weeks devising that system from scratch, hand-writing sorting algorithms, etc. The mental model of software development is abou…

We have libraries that solve many problems for us.

But those libraries often have parameters, switches, hints, and secret knowledge of the type "do not solve problem X by doing Y because although it seems okay on the surface, the implementational details will increase the complexity from O(N) to O(N^2); use this trick instead".

So we use libraries to solve the problems, but we also need years of experience using those libraries, or we easily create problems we didn't expect. Often there are many alternative libraries for the same task, and the library-specific knowledge becomes obsolete in later version.

Re: Don't write bugs

#100

Post by jimmaswell »

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.…

This is exactly like the classic fighting game advice "don't get hit"
Post reply on HN