[deleted]
You should write "without bugs"
31–40 of 91 posts
Re: You should write "without bugs"
#32I think this article completely misses the point. “Just be better” is only useful advice to the extent that you hear “don’t ship things that you know to suck”, which, let’s face it, many of us probably have at one time or another.
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”.
Re: You should write "without bugs"
#33This 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?
Re: You should write "without bugs"
#34I 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.
I think there's always argument that you don't know what you don't know. How much thought do you put on writing code with out bugs. Bug could be caused by the business logic, the language internals, the runtime environment internal and variation. I think what people often ignore writing piece of software is an iterative process, you build, deploy and learn from the operation and you fix and repeat. If you keep thinki…
> writing piece of software is an iterative process
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.
Re: You should write "without bugs"
#35In 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.)
Re: You should write "without bugs"
#36with ants
Re: You should write "without bugs"
#37Would need a robust definition of "bugs" to learn whether one is shipping "bugs" or not. To learn why that would be important to know is another matter worth looking into.
Some of the most successful softwares are horribly bugridden.
Re: You should write "without bugs"
#38Earlier quoted context omitted.
I think there's always argument that you don't know what you don't know. How much thought do you put on writing code with out bugs. Bug could be caused by the business logic, the language internals, the runtime environment internal and variation. I think what people often ignore writing piece of software is an iterative process, you build, deploy and learn from the operation and you fix and repeat. If you keep thinki…
> writing piece of software is an iterative process 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 profitabl…
I mostly agree with you.
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
Re: You should write "without bugs"
#39> 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.
Re: You should write "without bugs"
#40This 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.
I dont think the author's goal (or reality) is perfection, zero bugs. A fluent English speaker, even an English professor, will occasionally trip up on a word or write a confusing sentence. But if thoughtfulness and planning reduce 80% of bugs or more, that's a big win.