You should write "without bugs"

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 the class helped improve my program quality nonetheless. Now I generally think in terms of a program being correct rather than having no bugs. Technically these are the same thing, but the change of language brings a change of focus. I generally try to use the term "error" instead of "bug", for an incorrect program.

My strategy is to write the simplest correct version of the program first, convince myself that it is correct, and then optimize, if necessary without regressing on correctness. I generally use tests, rather than formal proofs, though, so of course there is still the possibility of uncaught errors, but this strategy works well overall.

Thinking this way also gives me guidance as to how to break down a program into modules and subprograms: anything that is too big or complex for me to be able to reason about its correctness must be subdivided into pieces with well-defined correctness.

It also has clarified for me what premature optimization means: it is optimizing a program before you know it's correct.

(EDIT: fixed "reason about its complexity" to say "reason about its correctness" in the penultimate paragraph.)

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.

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 in your head at a time. (Compare for instance the well-known increased ability of chess masters to memorize chess boards, compared to non-chess players.)

When you’re an inexperienced programmer, you need to write the code down (and run it to test if it works) before you know if the code and algorithm solves the problem. This makes the inexperienced programmer take shortcuts while writing down the code, in order to get the code written down as fast as possible, while it is still clear in their mind.

The experienced programmer, on the other hand, can easily envision the entire algorithm in their head beforehand, and can therefore spare some extra attention for adding error checking and handling of outlier cases, while writing the code for the first time.

Also, as the article states, when you make a conscious habit of always writing code which checks for all errors and accounts for all outliers, it becomes easier with time; practice makes perfect, as it were. This is essentially a way to speed up the natural process described above.

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.

I will remember this advice the next time I decide to write a bug.

In a college chemistry lab we would have to write lab reports of our work. The instructor made it very clear that he has never given 100% on a lab reports because there's always something to improve.

A one of my CS cohorts happened to be in the same class so we teamed up for the first lab project. It was pretty straightforward, we collected whatever information, and started working on our report. We didn't bother spending much time on it because we already knew we'd lose points for something or another.

When we got it back, there was a big, red "100" on top. We checked around and it did look like we were the only ones that got a perfect score, so we went to the instructor and, mostly jokingly, said, "What's up with this?" to which he stayed on beat and replied, "Do you want me to take another look?"

It's not hard to do good work, but you do have to make a habit of it. Re-read what you write, preferably out loud, to make sure it actually makes sense.

You'll still make errors and mistakes and you won't catch them all, but no one's going to care about a typo or two unless you draw attention to it with more glaring problems. And I think this is where metrics, especially things like code coverage, can actually be detrimental, because they bring attention to the wrong things.

Specifically, in places I've seen code coverage enforced, tests (written by consultants making x5-10 more than I do) tend to look like, `assert read_csv("foo,bar") == [["foo", "bar"]]` that execute enough of the function to satisfy the coverage requirements, but everyone is surprised when things break using a real CSV document.

The corollary of the author's trick is that if you keep making excuses to produce poor work, you may subconsciously decline instead.

This feels like fluff. You can think a few steps all you like but bugs will creep in, those you can’t think about, those in areas you don’t quite understand, those that require weird sequences of events.

> My “trick” during that final year was simple: I always tried to write correctly, not just when I was asked to, but all the time. After a year of subconscious improvements, I aced the exam.

Practice makes permanent. Perfect practice makes perfect.

This is pretty spot-on. A culture of testing everything will ossify code by not understanding what a "unit" is and amplifying developer churn by testing implementation details instead of the actual units. A culture of just getting features out the door will suffer under the weight of every change dragging on all future changes.

If you want to really get code that can be adapted whenever requirements change, you need to be thoughtful. Understand the code you write. Understand the code you choose not to write. Understand the code that was there before you got there. Think about the edge cases and handle them in a way that makes sense.

I'd call it "practicing writing code without bugs" rather than "writing code without bugs", though. In the end it's a practice. Is it going to be what you work towards every day, or is just an afterthought?

I do my best. I usually have so few bugs in my final ship products, that it's not worth it to have a tracker.

Getting there, though, I have lots of bugs. It's just that I want them gone, before I pat my app on the butt, and send it out into the field.

I often see people use Voltaire's phrase "Perfect is the enemy of the good," to justify writing bug farms. I'm not sure that this is what he meant.

Functional Core - are you unit testing side effects?

https://www.destroyallsoftware.com/screencasts/catalog/funct...

https://hn.algolia.com/?q=functional+core

I don't think anyone says you should just casually ship bugs. Quite the contrary, most are ok with the idea that, if you see a bug, fix the bug. But, there can be no doubt that there is diminishing returns on chasing down every potential bug.

This reads to me like the idea that a rich person walking down the road wouldn't pick up a $20 they happen to see at their feet. Of course they will. Why not?

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.

Similarly, use your tools to write as efficient and bug free code as you can. Make it as flexible and allow for any future changes you can accommodate along the way. But "along the way" should be "along the way of delivering things in a timely manner." If you stray from that, course correct.