The Zero-Bug Policy in Software Development
1–10 of 26 posts
Re: The Zero-Bug Policy in Software Development
#2Summary:
Have a "zero bug policy" in 1 simple step:
Re-classifies bugs you don't want to fix as "improvements".
Tada!
... Seriously? That's ridiculous click-bait crap. You didn't implement a zero-bug policy, you just redefined what you call a bug. This is no different than everyone else's policies, except that now you're screwing with terminology.
Re: The Zero-Bug Policy in Software Development
#3Summary: Have a "zero bug policy" in 1 simple step: Re-classifies bugs you don't want to fix as "improvements". Tada! ... Seriously? That's ridiculous click-bait crap. You didn't implement a zero-bug policy, you just redefined what you call a bug. This is no different than everyone else's policies, except that now you're screwing with terminology.
You missed the part about making them the top priority after you reclassify them.
After that, you are right, it's that simple. I even state that in the article that it's not complicated. Yet, not many seem to do it.
Click-bait? Not quite. I'm someone that is writing to genuinely provide my experience to others. In the article I discuss why it works and what it does in the long run. Where the origins of Zero-Defect comes from etc etc.
Sorry you didn't find it useful, I hope that some do, and I hope that you and your team are the type that don't need this advice.
Re: The Zero-Bug Policy in Software Development
#4Summary: Have a "zero bug policy" in 1 simple step: Re-classifies bugs you don't want to fix as "improvements". Tada! ... Seriously? That's ridiculous click-bait crap. You didn't implement a zero-bug policy, you just redefined what you call a bug. This is no different than everyone else's policies, except that now you're screwing with terminology.
[deleted]
Re: The Zero-Bug Policy in Software Development
#5Summary: Have a "zero bug policy" in 1 simple step: Re-classifies bugs you don't want to fix as "improvements". Tada! ... Seriously? That's ridiculous click-bait crap. You didn't implement a zero-bug policy, you just redefined what you call a bug. This is no different than everyone else's policies, except that now you're screwing with terminology.
You missed the part about making them the top priority after you reclassify them. After that, you are right, it's that simple. I even state that in the article that it's not complicated. Yet, not many seem to do it. Click-bait? Not quite. I'm someone that is writing to genuinely provide my experience to others. In the article I discuss why it works and what it does in the long run. Where the origins of Zero-Defect co…
The article is only about known bugs that are sitting in a bug database, which makes the entire piece trivial.
The main concern in software quality turning unknown bugs into known bugs, not with reshuffling the type and priority fields in a bug database (which is of course important).
"Zero bugs" means "exhaustively tested or else proved correct" (given a perfect set of high level requirements and detailed specification to begin with).
Any other use of "zero bugs" in a headline is clickbait.
The bugs that screw you are the unknown ones. Like security exploits that the Bad Guys find in the field before you do.
Re: The Zero-Bug Policy in Software Development
#6Summary: Have a "zero bug policy" in 1 simple step: Re-classifies bugs you don't want to fix as "improvements". Tada! ... Seriously? That's ridiculous click-bait crap. You didn't implement a zero-bug policy, you just redefined what you call a bug. This is no different than everyone else's policies, except that now you're screwing with terminology.
Perhaps I am wrong here, but I got a much different message out of the post.
It's not about actually having ZERO bugs as it is about enforcing a strict and logical classification system.
I think this quote resonated with me the most:
> ...but much more so, the bugs were a result of incorrect specification or missing specifications.
The argument being made is that if you hand a developer a specification, the developer implements the specification _as specified_, then you discover the specification was incorrect or that in practice you want a change would you classify that as a _BUG_? No. But a lot of shops _do_, so they end up with _too_ many tasks classified as a "Bug" which makes it impossible to prioritize since being a "Bug" is a binary descriptor.
By enforcing a classification system means you have the ability to then enforce a prioritization system...and really the prioritization system is key for maintaining consistent output and forward progress.
At least that what I felt the argument of the post was...and I see some reasonability to it. Especially since, as the author mentioned, this is not a new idea.
Re: The Zero-Bug Policy in Software Development
#7Earlier quoted context omitted.
You missed the part about making them the top priority after you reclassify them. After that, you are right, it's that simple. I even state that in the article that it's not complicated. Yet, not many seem to do it. Click-bait? Not quite. I'm someone that is writing to genuinely provide my experience to others. In the article I discuss why it works and what it does in the long run. Where the origins of Zero-Defect co…
The article is only about known bugs that are sitting in a bug database, which makes the entire piece trivial. The main concern in software quality turning unknown bugs into known bugs, not with reshuffling the type and priority fields in a bug database (which is of course important). "Zero bugs" means "exhaustively tested or else proved correct" (given a perfect set of high level requirements and detailed specificat…
Again, I responded elsewhere, but I don't think the article was about actually having ZERO bugs. It was about enforcing a strict classification system so you can implement a reasonable prioritization scheme (Critical issues and Bugs are fixed FIRST by distinguishing what are actually bugs and what are Improvements).
So it's an article on the development lifecycle and how to get consistent forward progress with some organizational improvements. It's not actually about writing software with "Zero" bugs.
Re: The Zero-Bug Policy in Software Development
#8Summary: Have a "zero bug policy" in 1 simple step: Re-classifies bugs you don't want to fix as "improvements". Tada! ... Seriously? That's ridiculous click-bait crap. You didn't implement a zero-bug policy, you just redefined what you call a bug. This is no different than everyone else's policies, except that now you're screwing with terminology.
Perhaps I am wrong here, but I got a much different message out of the post. It's not about actually having ZERO bugs as it is about enforcing a strict and logical classification system. I think this quote resonated with me the most: > ...but much more so, the bugs were a result of incorrect specification or missing specifications. The argument being made is that if you hand a developer a specification, the developer…
> about enforcing a strict and logical classification system.
But that is something so common place that even pretty poorly run software organizations which ship crap do it.
The rhetorical Everyone has a bug database with features, enhancements, low priority bugs and "blockers". That plus version control is the bare minimum requirement for having any kind of process distinguishable from total chaos.
This is an article about water being wet.
Re: The Zero-Bug Policy in Software Development
#9Earlier quoted context omitted.
Perhaps I am wrong here, but I got a much different message out of the post. It's not about actually having ZERO bugs as it is about enforcing a strict and logical classification system. I think this quote resonated with me the most: > ...but much more so, the bugs were a result of incorrect specification or missing specifications. The argument being made is that if you hand a developer a specification, the developer…
> about enforcing a strict and logical classification system. But that is something so common place that even pretty poorly run software organizations which ship crap do it. The rhetorical Everyone has a bug database with features, enhancements, low priority bugs and "blockers". That plus version control is the bare minimum requirement for having any kind of process distinguishable from total chaos. This is an articl…
Perhaps, but having worked for a government sub-contractor that had precisely this problem, I don't think it's as universally true as you would think.
At that particular company, everything was a "task" and tasks were just thrown at employees as they came. This wasn't just limited to software development either...this applied to customer support and service as well.
Their solution, and the solution the customer (government contractors) was to schedule numerous and regular meetings in order to touch base and monitor progress...which only contributed to the problem.
Also the article itself is actually a case study...
Re: The Zero-Bug Policy in Software Development
#10Summary: Have a "zero bug policy" in 1 simple step: Re-classifies bugs you don't want to fix as "improvements". Tada! ... Seriously? That's ridiculous click-bait crap. You didn't implement a zero-bug policy, you just redefined what you call a bug. This is no different than everyone else's policies, except that now you're screwing with terminology.
You missed the part about making them the top priority after you reclassify them. After that, you are right, it's that simple. I even state that in the article that it's not complicated. Yet, not many seem to do it. Click-bait? Not quite. I'm someone that is writing to genuinely provide my experience to others. In the article I discuss why it works and what it does in the long run. Where the origins of Zero-Defect co…
It's a useful classification system, but calling it "zero bugs" is basically a lie. Whether something is labeled critical/bug or not is based on importance, not whether it's actually a bug.