Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Zero-Bug Policy in Software Development

medium.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: The Zero-Bug Policy in Software Development

#11

Post by samhatoum »

Dylan16807 wrote: post #10
samhatoum wrote: post #3

Earlier 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…

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.

It's not really a lie when you think about it. It's very true to its name.

It's saying, after you've classified the bugs, you're not to do any other work until the bug list is cleared. This will lead you to zero-bugs (of the known ones of course).

I've implemented and seen this first-hand in 4 different companies.

Re: The Zero-Bug Policy in Software Development

#12

Post by samhatoum »

kazinator wrote: post #5
samhatoum wrote: post #3

Earlier 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…

As gshulegaard has mentioned, I think you're taking the name Zero-Bug to mean something different than what I intended.

Zero-Bug does not mean writing software without defects - that's impossible, instead it means correctly classifying bugs and then striving to keep the bug-count at 0.

I've written another article on the three types of bugs, and one of those is the "unknown ones" you refer to. There are things you can do to tease out some unknowns, but of course there's no cure for bugs as a whole. It's here if you're interested: https://goo.gl/TlvNcY

On the clickbait, I assure you it's not. I labelled the approach Zero-Bug long before writing the article. It creates an attitude in a team. After I've worked with teams to clarify what Zero-Bug really means, they strived towards doing more checks before even pushing out code. We celebrated Zero-Bug days when we were actually down to 0 and believe it or not, I've seen up to 2 iterations at a go be free of bugs. Coincidence? I don't think so.

Re: The Zero-Bug Policy in Software Development

#13

Post by Dylan16807 »

samhatoum wrote: post #11
Dylan16807 wrote: post #10

Earlier quoted context omitted.

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.

It's not really a lie when you think about it. It's very true to its name. It's saying, after you've classified the bugs, you're not to do any other work until the bug list is cleared. This will lead you to zero-bugs (of the known ones of course). I've implemented and seen this first-hand in 4 different companies.

That's not the part I'm calling a lie.

Let me word it differently.

You classify tickets into categories A,B,X,Y. You always clear out A and B before doing anything else. As a strategy to have "zero unresolved important issues", it's valid.

The disconnect is between the "Bug" ticket category, and the actual definition of what a bug is.

"Web font is being downloaded when it should be embedded in the app" is clearly a bug, by the normal definition of bug.

This system classifies by priority to get Critical/"Bug"/Other, and it further divides the lowest priority into new features vs. changing features. At no point does it ask if something is a mistake. It doesn't care. So it shouldn't use the word 'bug'. It tricks people into thinking it's something it's not.

Re: The Zero-Bug Policy in Software Development

#14

Post by samhatoum »

Dylan16807 wrote: post #13
samhatoum wrote: post #11

Earlier quoted context omitted.

It's not really a lie when you think about it. It's very true to its name. It's saying, after you've classified the bugs, you're not to do any other work until the bug list is cleared. This will lead you to zero-bugs (of the known ones of course). I've implemented and seen this first-hand in 4 different companies.

That's not the part I'm calling a lie. Let me word it differently. You classify tickets into categories A,B,X,Y. You always clear out A and B before doing anything else. As a strategy to have "zero unresolved important issues", it's valid. The disconnect is between the "Bug" ticket category, and the actual definition of what a bug is. "Web font is being downloaded when it should be embedded in the app" is clearly a b…

Actually this is where you can be flexible with a specification. If the ticket was initially specified as embedding the fonts, then technically it's an implementation defect since it was already specified. However, as a team you might decide it's not too bad to download fonts instead of embedding them. This is where you can be flexible with the solution. Instead ob being rigid with expectation when the reality is the bug can comfortably be re-classified.

If however the loading time with downloading the fonts is something the team is not as per the team's quality standards and they are not willing to live with it, then it should absolutely remain as a bug.

Now that the classification portion is out of the way, the team priority is to work on bugs first no matter what.

So I'm saying that "the actual definition of what a bug is" should be stated as a guideline and the team can decide on an ongoing basis. Some guidelines might be rigid, others not so much.

Re: The Zero-Bug Policy in Software Development

#15

Post by Dylan16807 »

samhatoum wrote: post #14
Dylan16807 wrote: post #13

Earlier quoted context omitted.

That's not the part I'm calling a lie. Let me word it differently. You classify tickets into categories A,B,X,Y. You always clear out A and B before doing anything else. As a strategy to have "zero unresolved important issues", it's valid. The disconnect is between the "Bug" ticket category, and the actual definition of what a bug is. "Web font is being downloaded when it should be embedded in the app" is clearly a b…

Actually this is where you can be flexible with a specification. If the ticket was initially specified as embedding the fonts, then technically it's an implementation defect since it was already specified. However, as a team you might decide it's not too bad to download fonts instead of embedding them. This is where you can be flexible with the solution. Instead ob being rigid with expectation when the reality is the…

You can make whatever categories you want. But if your definition of "bug" is in disagreement with the rest of the world, don't tout it as having "zero bugs". Just pick a different word, one that doesn't mislead.

Re: The Zero-Bug Policy in Software Development

#16

Post by kazinator »

samhatoum wrote: post #12
kazinator wrote: post #5

Earlier quoted context omitted.

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…

As gshulegaard has mentioned, I think you're taking the name Zero-Bug to mean something different than what I intended. Zero-Bug does not mean writing software without defects - that's impossible, instead it means correctly classifying bugs and then striving to keep the bug-count at 0. I've written another article on the three types of bugs, and one of those is the "unknown ones" you refer to. There are things you ca…

You're working with a definition of "Zero Bug" that doesn't arise from the meanings of "bug" and "zero" combined together in the obvious, orthogonal way.

There are such compounds entrenched in the English language (like "new wave" or "blackboard") but they take decades to enter general use.

I don't think we need "zero bug" to be a non-compositional compound of this type. The terms "bug" and "zero" are too significant in computing for us to allow them to be hijacked like this.

For instance, we wouldn't redefine "zero latency" as being 5 seconds (say, in a situation in which we can't get it any shorter for the given span, due to the distance and the speed of light). Latency is latency, zero is zero, and five seconds isn't zero.

I urge you to reconsider your use of technical language.

Re: The Zero-Bug Policy in Software Development

#17

Post by tostitos1979 »

gshulegaard wrote: post #6
wccrawford wrote: post #2

Summary: 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…

I'm in the business of building complex software systems, and I think another way to improve software development is to fire all the agile coaches, use the money saved to hire more developers, and use those developers to give the team more help to fix defects and add features. I really cringe when a project management type comes in and points out the obvious. This kind of stuff only works if you are building simple software like a CMS system or a basic CRUD app. Building complex software is an exploration in and of itself. In the old telecom days, months would be spent writing precise feature specifications and design documents. That's how much time it takes. Does ANYONE have that time today? Aside from safety critical systems where you have no choice but to put in the time, I think the answer is no. The software development process has shrunk significantly, and as an industry we have decided to meld design, architecture, feature specification, coding and testing. Bugs are a necessary end product of this stupidity.

Re: The Zero-Bug Policy in Software Development

#18

Post by samhatoum »

kazinator wrote: post #16
samhatoum wrote: post #12

Earlier quoted context omitted.

As gshulegaard has mentioned, I think you're taking the name Zero-Bug to mean something different than what I intended. Zero-Bug does not mean writing software without defects - that's impossible, instead it means correctly classifying bugs and then striving to keep the bug-count at 0. I've written another article on the three types of bugs, and one of those is the "unknown ones" you refer to. There are things you ca…

You're working with a definition of "Zero Bug" that doesn't arise from the meanings of "bug" and "zero" combined together in the obvious, orthogonal way. There are such compounds entrenched in the English language (like "new wave" or "blackboard") but they take decades to enter general use. I don't think we need "zero bug" to be a non-compositional compound of this type. The terms "bug" and "zero" are too significant…

I like you're reasoning!

There is no situation where zero latency actually means a latency of zero, whereas in the description I've provided there is a situation where you end up with zero bugs.

Out of interest, what would you call the action of striving towards zero bugs?

Re: The Zero-Bug Policy in Software Development

#19

Post by kazinator »

samhatoum wrote: post #18
kazinator wrote: post #16

Earlier quoted context omitted.

You're working with a definition of "Zero Bug" that doesn't arise from the meanings of "bug" and "zero" combined together in the obvious, orthogonal way. There are such compounds entrenched in the English language (like "new wave" or "blackboard") but they take decades to enter general use. I don't think we need "zero bug" to be a non-compositional compound of this type. The terms "bug" and "zero" are too significant…

I like you're reasoning! There is no situation where zero latency actually means a latency of zero, whereas in the description I've provided there is a situation where you end up with zero bugs. Out of interest, what would you call the action of striving towards zero bugs?

I'm not sure about what glib phrase I would use (say, consisting of just two words) but the main idea in the overall approach is that we stay on top of critical bugs. If we have critical bugs, we don't do anything else until they are solved. We don't polish the chrome on some shiny new feature, while a fire is raging. So this is "Bugs First" or something. Except it's not all bugs first, just the showstoppers. "Fires First?" Hmm, what's a glib word that clearly means "show-stopper defect"?

Another way to approach this is from the angle of: no customer is left to dangle in a situation where they aren't getting value from the product, where they are faced with an issue for which there is no feasible workaround, or some security breach. What's a glib phrase which quite precisely conveys the idea that try to prevent this situation at all costs, and get them out of it ASAP if it happens?

Re: The Zero-Bug Policy in Software Development

#20

Post by samhatoum »

tostitos1979 wrote: post #17
gshulegaard wrote: post #6

Earlier 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…

I'm in the business of building complex software systems, and I think another way to improve software development is to fire all the agile coaches, use the money saved to hire more developers, and use those developers to give the team more help to fix defects and add features. I really cringe when a project management type comes in and points out the obvious. This kind of stuff only works if you are building simple s…

FYI, I'm not a project management type. I've build numerous continuous delivery pipelines for enterprise clients and helped them deliver multiple features per week. I have current skills in writing Java, C# and Node.js. I've written my own testing frameworks (Check out Chimp.js), I coach developers on how to write better code, as well as business people on how to create better specs.

I typically try to stay away from CRUD applications where possible as I find them too simple. I prefer to work on meaty domain-driven applications using CQRS and Event sourcing, but that's just my tech preferences.

I too worked in telecoms and was part of the development team that did the AOL LLU from BT in the UK. The old-world you speak about has a ton of wisdom in it, that much I agree with you on, however it was also riddled with stupidity of its own.

The amount of time you put into the specs is not where the trick is in my view, it's about splitting the specs down into manageable chunks (something the old world never understood) and then making sure those chunks get the necessary time (something often missed these days).

If you think the solution for your company is not to have any advisors, and that you have all you need, then by all means hire more developers. They are the smartest people around ;)

Post reply on HN