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

21–26 of 26 posts

Re: The Zero-Bug Policy in Software Development

#21

Post by samhatoum »

Dylan16807 wrote: post #15
samhatoum wrote: post #14

Earlier quoted context omitted.

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.

I don't think the world has an agreed definition of a bug, or at least I've not seen it!

I understand that the issue people have is with the wording of the zero-bug. As I've mentioned elsewhere it's still true that it is a striving towards zero-bug and I've seen it first hand where we get to 0 known bugs.

I'll meditate on this a little and see what I come up with. I really do appreciate this feedback :)

Re: The Zero-Bug Policy in Software Development

#22

Post by samhatoum »

kazinator wrote: post #19
samhatoum wrote: post #18

Earlier quoted context omitted.

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…

It's not just about critical bugs though. Those are "stop what you're doing and get on it". ANY bug that is not critical gets worked on next no matter what. So it's about all bugs getting priority over other work.

It's akin to an immune system. When a bug is found, it's attacked until it's dead.

I really appreciate this feedback. As there are a few people that the phrase is rubbing up the wrong way, I'll meditate on it a little and see what I come up with.

Re: The Zero-Bug Policy in Software Development

#23

Post by kazinator »

samhatoum wrote: post #22
kazinator wrote: post #19

Earlier quoted context omitted.

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…

It's not just about critical bugs though. Those are "stop what you're doing and get on it". ANY bug that is not critical gets worked on next no matter what. So it's about all bugs getting priority over other work. It's akin to an immune system. When a bug is found, it's attacked until it's dead. I really appreciate this feedback. As there are a few people that the phrase is rubbing up the wrong way, I'll meditate on…

I understand; but it's hard for some convenient phrase to cover every aspect of the process. So in the end there has to be some understanding that it's the name of some process that has more aspects than just the literal meaning. (Just like "Zero Bugs").

Re: The Zero-Bug Policy in Software Development

#24

Post by Dylan16807 »

samhatoum wrote: post #21
Dylan16807 wrote: post #15

Earlier quoted context omitted.

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.

I don't think the world has an agreed definition of a bug, or at least I've not seen it! I understand that the issue people have is with the wording of the zero-bug. As I've mentioned elsewhere it's still true that it is a striving towards zero-bug and I've seen it first hand where we get to 0 known bugs. I'll meditate on this a little and see what I come up with. I really do appreciate this feedback :)

Definitions very somewhat, but I think very few people would say that the business impact of a problem changes whether it's a 'bug'.

Re: The Zero-Bug Policy in Software Development

#25

Post by tostitos1979 »

samhatoum wrote: post #20
tostitos1979 wrote: post #17

Earlier quoted context omitted.

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…

I didn't mean a personal attack on you btw. Your track record suggests you know your stuff and would likely be an asset on a large/complex project. My comment is informed by my bad experiences at two previous employers - both parachuted agile coaches to "help" when the problems were obviously a runaway feature list and not enough developers. Surely, you must know of charlatans in connection with agile. I think we all need to educate management that agile is not a silver bullet or a panacea. It is a process with good and bad. Great if welded by adults but very easy to abuse by non-grownups. To many of my developer friends, agile is a synonym for daily status updates, which is absolutely not what it is supposed to be.

Re: The Zero-Bug Policy in Software Development

#26

Post by samhatoum »

tostitos1979 wrote: post #25
samhatoum wrote: post #20

Earlier quoted context omitted.

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…

I didn't mean a personal attack on you btw. Your track record suggests you know your stuff and would likely be an asset on a large/complex project. My comment is informed by my bad experiences at two previous employers - both parachuted agile coaches to "help" when the problems were obviously a runaway feature list and not enough developers. Surely, you must know of charlatans in connection with agile. I think we all…

Thanks for the clarification and totally agree. I have seen project managers turn their gantt-chart sideways, have 1 hour standup meetings and call themselves Scrum Masters! So I know exactly what you mean.

Nowadays I never say the A word in a companies for the exact reasons you mention. Now I say "let's start producing higher quality, faster" and go from there.

Post reply on HN