Bugs Are a Signal

Bugs Are a Signal

Most development teams and organisations seem to accept that “bugs happen”. It might not be a stretch to say that most developers [and testers] seem to accept it, too. Few seem inclined to look at the origins of bugs in their software products.

Aside: Some few teams and organisations do have some kind of “causal analysis” for defects a.k.a. bugs. I wonder how many of these get down to the real root causes?

Many external observers (external to the systems within which bugs are created) suggest that bugs are due to a number of causes, including:

• Unclear requirements
• Coding errors
• Gaps in communication
• Complexity of the software
• Shortage of time to do an adequate job

As a practitioner and observer, I have a different proposition:

Bugs are caused by
a lack of engagement,
a low level of commitment to the work,
absence of motivation.

Allow me to make the case for this proposition, with reference to the above list of causes:

Unclear Requirements

If the requirements are unclear, why do developers not seek clarification? Because they are not motivated to do so. This may be due to a number of different reasons, including lack of convenient access to customers, product owners or business analysts, or because they see the quality (clarity) of the requirements as somebody-else’s-problem.

Coding Errors

Coding errors typically stem from developers lacking sufficient knowledge of the tools (languages, libraries, APIs, etc.) at hand. A lack of knowledge illustrates a lack of learning, this in turn due to a lack of motivation to learn. Some might say that some coding errors are simply “unavoidable human error” – this may be so in the first instance, but what prevents developers from diligently proof-reading and otherwise testing their own code (or each other’s) for such errors? What indeed, excepting low motivation?

Gaps in Communication

If there are gaps in communication, why do developers (and other parties) not seek to close those gaps? Again, I posit a lack of motivation to do so, including a lack of motivation to identify and acquire the relevant skills.

Complexity of the Software

Complexity generally arises from developers taking the shortest path between problem and solution. I suggest a lack of motivation is the causal factor in developers not investing the extra time and thought into simplifying things. Some might say that some developers lack the skill or talent to reduce complexity. That may well be true. But what prevents these more “challenged” developers from seeking help from specialists and senior people – what but a lack of motivation so to do?

Shortage of Time

Rarely do developers have the time they would like to do an adequate job. Again, I posit that a lack of motivation plays a key part in persuading them to not push back against unreasonable demands and schedule pressures, instead resigning themselves to quietly do a half-assed job, rationalising away their chagrin at the “necessary” ugly compromise (see also, below). And from the other side, what but a lack of motivation accounts for managers’ not understanding the developers’ concerns, not listening to their explanations of how long it will take to do an adequate job, not reaching a consensus on what “adequate” even means?

Other Sources

If you can think of any other sources of bugs (a.k.a. defects), I invite you to consider how such a source (cause) might be explained by a lack of motivation, engagement, interest and/or commitment.

The Impact of Low Motivation

In general, a lack of motivation increases the likelihood that folks will skimp on the quality of their work, most often with rationalisations (be they conscious or subconscious) such as:

• “No one will notice.”
• “It’ll probably be OK.”
• “They’ll catch it in testing.”
• “I’ll come back to that later.”
• “Someone else can fix that.”
• etc..

Motivation is a System Condition

I am not suggesting that developers need to “take more care” or “get motivated”. I’m not attempting to blame folks for not caring enough about the quality of their work. Far from it. I’m suggesting that the way the work works lies at the heart of whether folks are motivated or not.

Bill Deming also points out that:

“A bad system will defeat a good person every time.”

and attributes circa 95% of a worker’s contribution to the way the work works, and only 5% to their own motivation, skills, talent, etc. Is this a paradox? Not if we consider that the system (the way the work works) has an overwhelming impact on the motivation of the individuals working within it.

The Science of Motivation

Dan Pink talks and writes extensively about the things that affect motivation of i.e. knowledge workers. He attributes motivation (aka engagement, commitment) to three main factors:

• Autonomy
• Mastery
• Purpose

Accepting this, we might care to ask: how to arrange things such that folks have autonomy, mastery and purpose (Pink), or joy in work, cooperation, intrinsic motivation, self-esteem and learning (Deming) in their work? How should the work work, to optimise these factors? And, by the way, who typically has the whip-hand in such arrangements?

In closing, I’d like to suggest that the presence of bugs most often indicates low morale and a lack of motivation. Organisations can chose to act on this signal, and seek to address the contributing system conditions, or go buy a bug (tracking) database and bury the signal there.

– Bob