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

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.

Writing code without 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.

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.

This feels like fluff. You can think a few steps all you like bug 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.

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

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?

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.

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

> In the end, this all becomes muscle memory. You’ll be able to write code that’s not buggy, yet still ship at a good speed without thinking when you shouldnt and thinking much more when you should.

I'm very skeptical of this. You can't really have it both ways. I believe someone when they tell me they can ship code without bugs, but only by taking a lot of time, including the time necessary to test and debug the relatively fewer bugs they produce. But, I find it hard to believe someone who says that through pure self-discipline and force of will, they can just not write bugs without sacrificing speed.

And, generously, if there is someone who can do this, I find it hard to believe it's a generalizable methodology. "Just decide not to write any bugs... why didn't I think of that?"

I guess the third possibility is that you can ship code quickly without bugs, but only if it's trivial code. I would believe that, but I don't think that's what he's saying. This seems like an extraordinary claim.

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.