samhatoum

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.

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.

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 :)

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 ;)

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?

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.

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.

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.

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.

Hey, this is the author.

The article is not at all marketing our services. It contains a ton of links that are intended to help you adopt BDD and TDD practices.

Tweets like this one back my response up: https://twitter.com/Cunninghambler/status/719608629729607681

I spent a LOT of time researching the data and making sure there are good links for learning.

Sam

Try this

https://github.com/xolvio/Letterpress/tree/master/app/tests/...

ES6 modules will change this approach somewhat, FYI