You should write "without bugs"
korshakov.com
korshakov.com
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.)
One obvious exception is code processing secret data. There, performance variance creates observable side-effects (timing side channels) which can be used to determine the secrets' values.
Another is any sort of hard real-time system, where performance is critical to correctness. For example, a brake-by-wire system that took 10 seconds to respond to the pedal being pressed would be incorrect, because of poor performance.
Otherwise, I agree. There might be some other exceptions, but striving for correctness first is a good way to write code.
It can be proven, in broadly the same sense as all of the atoms in your body can simultaneously "decide" to exist an inch to the right due to quantum field theory.
It is not practical to prove correctness for the vast majority of programs, and there are programs that are demonstrably incorrect, cannot be made correct, and yet are useful and still function anyway (e.g., closing TCP connections cannot be done "correctly").
That is the excuse i hear a lot from software developers, when everything they do is to test the expected behaviour of a program, without any edge case.
And this is also the reason why iMessage and WhatsUp are full of one click exploits.
These tools can take an extreme amount of time to use and require specialised skillsets that are difficult to hire for. They go far beyond standard software engineering practices like unit and E2E testing. It is genuinely, seriously not practical to verify the average startup's SaaS web app with TLA+; you'd go bankrupt.
Someone who's used them more than me might be able to comment on exactly how hard it would be, but I felt it was unfair to you not to explain.
Coq/Rocq are obviously much harder to use, and I mostly see embedded systems engineers use them. TLA+ is somewhat easier, and being used in a number of cloud infrastructure companies (AWS, MongoDB, Confluent etc).
Obviously, if you are building a simple CRUDL app, these tools don't help at all.
Wait, code is not simple. Are the requirements simple? Oh wait, in reality they aren't simple either.
The complexity of the formal specification must ramp up with the complexity of the code, because the task being asked is complex.
So where does the debugging end if the specification is wrong?
How do you prove the requirements are correct?
Unit testing is helpful but wasn't the panacea, because the most important bugs are in integration.
I'm also going to guess that formal proofs will have hellacious issues with system boundaries. They can't prove correctness of the state on the other end of the pipe.
So you overcome that, time and money. What happens when the requirements/specification changes? How much of the verification is invalidated?
Proof systems need to prove their economic validity in the he software realm. Heck, where are the proof systems for subsections of the Linux kernel or other vitally important inner loops of computing? Those actually have stable specifications. Weren't go multitasking formally verified/provably correct in some sense? Why haven't correctness tools tackled other things?
Any advice on reasoning about correctness?
"Software Development with Z. A practical approach to formal methods in software engineering"
https://archive.org/details/softwaredevelopm0000word/page/n1... .
there are other notations developed later. but its simplicity and easiness even while scribling on paper or word processor gets me back to using it every now and then
When I face a programming problem I map the solution to those simple building blocks, and If I can't I try to change the problem first.
Formal methods are hard if you want to prove the correctness of a hard algorithm, but you can almost always do without a hard algorithm and use something really basic instead, and for the basic things you don't need formal methods.
The people who write the most bugs in my experience do it because they don't fully understand the building blocks they're using, and rely on other things for correctness like the type checker or unit tests. They view code as a stochastic process, write code they don't fully understand and have accepted the resulting bugs as a fact of life.
Care to bring home the thesis on how that’s actually really insightful?
There are devs who don’t pay attention and devs who pay too much attention to context of the change they are implementing. I think author also outlined which things one might pay attention to so they would be considered careful.
I’ve caught multiple production bugs in code review by just carefully reasoning about the code and changing some variable names to match my mental model. I didn’t quite understand how bad it was, but I could tell it wasn’t right so I left a comment saying “this seems wrong”. What happened after? It was merged without addressing and it triggered a P1 regression in production two weeks later. Like the author said, it takes time and energy to truly understand a program and think through all the modes of execution. BUT I think it’s a worthwhile exercise. It just doesn’t really get rewarded. In my experience, this happened at least twice a year over my last 10 years of working in software.
The other example is blindly accepting AI generated code, which I think is an extension of copying template / boilerplate code. You take a working example and massage it to do what you want. It includes so many things that either aren’t needed or don’t make sense, but it works at first glance so it’s submitted and merged. For example, build configs, JSON or YAML configs, docker container build files, helm charts, terraforms, gradle builds. It takes a lot to learn these things so we often just accept it when it works. It’s exhausting to learn it all but if you do, you’ll be much better at catching weird issues with them.
I think the problem is we trick ourselves into thinking we should spend more time coding than anything else, but it’s everything else that causes us more problems and we should build the muscles to handle everything else so that we waste less time on those mistakes. We’re often already really good at shipping features but terrible at finding and handling bugs or configs or builds or infrastructure or optimizing for performance.
This is the entirety of the problem. Also why open source programs are so often "surprisingly" high quality.
Bad reward functions in companies don't just not reward people who do good work. It *actively punishes* them because stack ranking is a zero-sum game. And as much as people joke about stack ranking and lambast the dinosaurs who used to do it on purpose, it's still how it all actually work. It's just distributed stack ranking - each manager and manager of managers has their own local stack rank that bubbles up to who gets fired and who gets promoted.
So people who throw shit at the wall and make product that sell but have a shitty user experience get promoted and people who plod along and make things that work, or fix things that are broken (but not so much that they don't sell) filter to the bottom of the list and get cut, or leave when they don't get promoted or get raises.
Sure, there's some golden mix in between throwing shit at the wall and fixing key UX-ruining bugs. But these people still get outcompeted by people who purely ship n scoot.
If you keep thinking of all possible issues that can happen that becomes a blackhole and you dont deliver anything.
Often, yes. Absolutely.
> you build, deploy and learn from the operation and you fix and repeat.
But no, not at all in this way. This is generally not necessary and definitely not a mindset to internalize.
Commercial software products are often iterative, especially for consumer or enterprise, because they need to guess about the market that will keep them profitable and sustainable. And this speculative character has a way of bleeding down through the whole stack, but not for the sake that "bugs happen!" -- just for the sake that requirements will likely change.
As an engineer, you should always be writing code with a absolutely minimal defect rate and well-understood capabilities. From there, if you're working an a product subject to iteration (most now, but not all), you can strive to write adaptable code that can accomodate those iterations.
In first few iterations of writing the code, you often don't have complete picture of capabilities, capabilities change on the fly dictated by change in requirement. There is no baseline of what minimal defect rate it. Over period of time and iterations you build that understanding and improve the code and process.
I'm not saying that you don't think before you write code but often over thinking leads of unnecessary over engineering and unwanted complexity
I think the problem with the purists is that this is just a moral claim - it's not based on how businesses + marketplaces actually work. The lower you attempt to crank the defect rate (emphasis on the word "attempt"), the slower you will iterate. If you iterate too slow, you will be out-competed. End of discussion. This is as true in open-source as it is in enterprise SaaS. And in any case, you're just begging the question: how do we determine the "absolutely minimal" rate in advance?
> you can strive to write adaptable code that can accomodate those iterations.
This is a damaging myth that has wasted countless hours that could have otherwise been spent on fixing real, CURRENT problems - there is no such thing as writing "adaptable" code that can magically support future requirements BEFORE those requirements are known. If you were that good at predicting the future you would be a trader, not an engineer.
I presume you didn't use any Microsoft operating system (or program). /s
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.
A lot.
I always find bugs, when I test, no matter how "perfect" I think my code should be.
Also, I find that a lot of monkey testing is important. AI could be very beneficial, here. I anticipate the development of "AI Chaos Monkeys."
https://littlegreenviper.com/various/testing-harness-vs-unit...
Well, you just made me realise that there is still a use for those LLMs beside generating propaganda. The problem, i guess will be, that nobody will be willing to spend time on those bug reports.
That's basically a question of culture.
Bad culture will result in bad results, no matter what tools and techniques we use.
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.
When I test, I always find bugs. Never fails.
Watching this posting dive down from the HN front page has been interesting (and expected).
It’s rather discouraging to see how discussions of Quality Development are treated, hereabouts.
Quality seems to be heresy.
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.
Practice makes permanent. Perfect practice makes perfect.
It just takes a lot of work. No shortcuts.
But that WFM. YMMV.
If the goal is to make a program, I make sure that my thoughts about the program are sound before actually building it. If I need to play around a bit to understand the problem domain then I additionally need to be prepared to throw out the play-work. If I run into a bug, I remember it and proactively avoid it in the future. I think about the limitations of my design before I start building. This is my implementation of writing "without bugs"; it doesn't have to be perfect, it just can't be something which I know to be wrong.
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?
Yup. I have seen so many people write stuff that could just be a YAML script, tying together massive dependency trees that they have no clue about.
Then, they lose it, when things go pear-shaped.
However, if the goal is to sell the company before the chickens come home to roost, it's a feature, not a bug.
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.
https://www.destroyallsoftware.com/screencasts/catalog/funct...
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.
Why is it usually a waste of time? Because people rarely lose multiple bills of money, and if they do, our vision system is well equipped to spot the other bills quickly.
The opposite is often true with software in my experience.
When there is a bug, it's often because the software is in a state of imbalance and confusion, and there are multiple bugs nearby.
And humans tend to be relatively bad at spotting bugs.
So, when you see a bug it is usually worth spending a moment to reflect on whether you've fixed the bug properly and whether there are other bugs in the vicinity. It is likely to be worth it just for the bug fixes.
But there's also the learning effect that comes with it as described by TFA.
If I'm just caught by a strawman at the start of the essay, apologies on that. I legit don't know anyone that casually encourages bugs as long as you have features. Tolerances are a thing, but so is negligence.
It has many techniques described, that have since become Canon, and a number that have not aged so well.
One that is probably impractical, these days, is Step Through Your Code. He recommends stepping through every line of your code in a symbolic debugger, making sure that the code flow is what you expect, and the app state is appropriate.
Every now and then, I can do it. Often, when I’m already there, for something else. It really does work.
I'm not going to link to it, but there's an old post from someone here, that pretty much sums up the zeitgeist.
They say that if the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much.
That is, quite literally, making the conscious decision to "casually ship bugs."
The disaster I mentioned was particularly heartbreaking, because the tech was solid, and the people behind it, were good, but they absolutely refused to give respect to Quality, and everything went to shit.
Just look at the way any discussion of Quality Development gets treated on HN. This very post nosedived, ten minutes after it posted. The only reason that it’s still around, is because it must have been “second-chanced.”
Then mention subconscious skill, and I think some people improve with practice more than others, and there may be individual differences in the "Noise floor" of trivial mistakes, like swapping plus and minus for no reason you could explain, they're just in the same category and you vaguely pattern matched that an operator goes there, and didn't think about it because people don't analyze every single token like a robot.
I can ship code that is more or less bug free, and I always aim to do so, but I don't really consider the idea of directly writing good code.
I try to remove opportunities to fail, designing an architecture that I think wouldn't take a lot of skill to implement, and then write the code, and then assume I have still failed in every imaginable way, and check for those failures, even if I have looked over the code ten times and am sure that I didn't make some particular mistake.
This is generally how I think about life in general too, I'm always thinking "Use a protective case" instead of "Just don't drop it".
It feels close to just saying, make your code better and you will see less bugs.
I don't disagree but the product environment has a lot to do with how features get deployed and how closely a developer can match the real life deployment to their development setup.
World class experts make mistakes all the time, I think learning how to address bugs is probably a more valuable skill.
This is just “think correctly, and often, then, no more bugs”. Not helpful?
It's fun to spend a few lifetimes on the quest for the perfect tool.
That's the analogy to the author's story about their exam.
(I'm pretty sure the "no bugs" part is just hyperbole to make a point.)
Lately I've been victim of letting too much pressure from clients build and I ended up spending 5 days on a major feature (built on legacy messy code) and in the process of making it better and adding a new features I ended up breaking few things here and there, which didn't play nicely with my refactor. Which costed me another few days of work.
I guess I should've had an approach closer to what he describes, written few tests more before hand and taken more time to nail it without the delay.
I learned from that experience, but the mindset he talks about would've been more beneficial.
Oh, you've met my CEO and CTO. And all those at previous companies!
Airbrake, Rollbar, Datadog, New Relic mean nothing if you ignore bugs because you don't take the time to replicate them.
You also can't fix what you don't know, so you need some telemetry or reporting of not your happy path. You can't have a goal of bug free code if you don't measure bugs (that's not SMART goal because it's not measurable).
Unit Tests, Typing, Linting, a collaborative code review process are key to big free code.
In order to really prevent bugs, you need actual engineering.
This means understanding the constraints on a system, where bugs are likely to occur (perhaps not even in code your company writes - your OS can have bugs too!).
Shipping stuff that you subjectively feel is high quality is a good start, and it’s enough for a lot of industries, but it doesn’t mean “bug free”.
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.
Some of the most successful softwares are horribly bugridden.
applies to nearly everything.
I don't really approach code this way, but I do prefer to fully think through a problem before I begin banging it out. This has upsides and downsides. Honestly though, I am very wary of anyone in tech that says something "absolutely" has to be done a certain way. An example - I have a convention with executable convenience scripts where I will label them per environment, in the naming of the file, and separate them by directory that way. It often gets pointed or yelled at me about "DRY" being violated, and now I have to maintain 3 separate sources of these, etc., when I could simply have a parameter I pass in to do the same thing. That would make it "productionalized", why all this repeat code everywhere???
Well, yea, I could. But, knowing me and how long I've done certain things, it's stupid easy to forget in the moment when you're tired or distracted what you are doing and where and do the wrong thing in the wrong place - which can be a total disaster that far outweighs whatever I am gaining from DRY principles. I find the better engineers I work with aren't so strictly rigid with their thinking and tend to do the same types of cost/benefit/risk analysis to whatever approach they choose.
A lot of them have this bizarre idea that since bugs will happen anyway, there's nothing we can do to avoid them. Then they come up with some bad architecture, or poorly-thought-out convention, or use a problematic library, which makes it easier for logic bugs to happen later, when someone else changes a convention elsewhere that interacted with it.
There often is a way (usually multiple ways) to architect software to avoid bugs. What Rust does to memory bugs and Haskell does to state bugs, can often be done manually in other languages, for whole categories of logic bugs, by being careful with your conventions and making sure they are easy to follow correctly.
I.e. software can be designed to avoid bugs. That requires some thought many people don't care to put in.
You can write code without bugs all you want, you won't sidestep those two.
I mean, yes, of course. Don't write obvious garbage code. Don't take obvious shortcuts. Value your craft.
But you'll still have bugs. (So did Telegram, btw: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=telegram)
I mean when we talk about money and company can potentially bankrupt within few minutes because how easy today to move money, things can get south pretty quick