Yang

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

• Reduce total cost of ownership by reducing functionality testing.

• Reduce developer stress that lead to bugs.

• Meet deadlines. 

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.