Introduction
As developers we fear
yang, the “bug”. The focus of all development methodologies are
to eliminate yang, the bug. In doing so, it has become the elephant
in the room. Taking an approach that bugs are a natural and welcomed
part of software development, actually reduces the cost of ownership.
It also facilitates learning and leads to more maintainable, robust
solutions.
Getting your yang in
balance is rarely part of the development life-cycle. Most but not
all methodologies, all but ignore this facet of software development.
Many teams go to extraordinary lengths... and cost to eradicate the
bug.
And after all of that
work avoiding the feared elephant in the room, it's discovered that
you do indeed have a bug. And in many cases a cluster of bugs. This
quite often results in stressed developers working late into the
night. Hardly a recipe for success that typically leads to poor code
structure due to workarounds, replacing one bug with another and
missing delivery deadlines.
(personal note: workarounds are a blight
and should never ever be acceptable)
The Goals of Yang
The Tenants of Yang
- Only test the task as described.
- Resolve bugs after development.
- Be responsible for the yang.
Only test the task as described
In complex environments, testing all possible co-dependencies is counter-productive and expensive. That's not to say that co-dependencies are not taken into account.
Co-dependencies should be tested by the developer before completing the task. The problem is many developers, particularly new and junior developers, don't have a
full understanding of the solution universe (domain).
It's also unrealistic
to expect programmers to test for co-dependencies they may or may not
be aware of. Unfortunately this fear, driven by KPI's and
unforgiving team structures, leads to countless unproductive hours of
initial testing.
Resolve bugs after development
This is what separates
Yang from other components of implementation. Yang accepts and
expects bugs have been introduced during the development stage.
Being a component of software development and not a methodology in
itself, developers universally test the whole system at a point that
suits there development paradigm.
The results of
developer testing are documented and tasks assigned.
This iterative
stage is an important educational opportunity to facilitate a better
understanding. Team members, particularly new members, start to see
the big picture and get a deeper understanding of how various
dependencies inter-relate. Major issues are discovered during this
initial universal testing. Proceeding iterations “Only test the
task as described”.
Also by documenting
this process, managers are better equipped to estimate the time
required to debug an iteration. The time frame can vary
dramatically. A team of long-term senior developers require minimal
time, while a team of new recruits will take considerably longer.
While some project managers are already aware of this fact, it's
amazing how many are not. Or if they are, use the issues as an
excuse to bully developers.
Be responsible for the Yang
This tenant panders to
human nature. You can work in development environments where the
developers are well and truly outnumbered by support staff. But
whenever a bug is discovered in the field, blame is almost always
apportioned to the developer. Everyone else wipes their hands of the
issue! So with this is mind, these ancillary staff are no more than
a deceit. The development team are always responsible for any
undocumented feature. Whether in the field or discovered prior to
release, this discovery is actually a very positive outcome. It's an
opportunity to facilitate a better understanding of the solution's
problem domain.
That's not to diminish
the function of good support staff. Good support staff are worth
their weight in gold. It's just many support roles are vague in
description and filled by unqualified people. Also developers are in
a better position to effectively resolve these issues. Support staff
can spent countless hours recreating a bug, that when described to
the development team, is instantly obvious.
If the Yang fits...
Many development teams
promote themselves as agile because they're not purists in any
particular methodology. They “cherry pick” the different
components to suit there needs. Yang is just another component they
may wish to include into their agile methodology. In fact most
already do, it's just not by design. Its a neglected part of the
SDLC that needs to be shown due respect.
So what percentage of
development time do I contribute to Yang?
By separating it from
the mainstream development process and documenting the results,
you'll end up with data that can guide you. The guidance however can
be misleading because the idea behind yang is not to increase
development time but to reduce it.
The basic philosophy is
that $(yin + support) > $(yin yang + support) >>
$$(reputation).
Why call it Yang
I just figured I had to
give it some name. BAM for Bug Acceptance Model. D'FAB for Don't
Forget About Bugs! I called it Yang as in yin yang because yin
represents good code and yang represents bugs. More importantly yin
yang doesn't actually mean good/evil. Just as bug free code isn't
necessarily good code and bugs aren't evil.
History
Draft 22 April 2012.
