
The Zero-Bug Policy in Software Development - samhatoum
https://medium.com/quality-functions/the-zero-bug-policy-b0bd987be684#.pcpmebx1o
======
wccrawford
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.

~~~
gshulegaard
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.

~~~
tostitos1979
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.

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

~~~
tostitos1979
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.

~~~
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.

