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

  1. RevioCTO said:

    An interesting point of view, and you’re probably right. I was about to argue that it takes time to make everything perfect -and that the customer may not be willing to pay for that – but I’m not sure wether it’s true, as I have never seen someone make a perfect product before. 🙂

  2. Yes. Software people seem to assume that ‘bugs’ are an implicit requirement.
    As Philip Crosby already pointed out: “Quality is Free”. Hence ‘the customer may not be willing to pay for that’ is not even an issue. Crosby wrote about “Zero Defects”, which does not mean not that we suddenly don’t cause defects any more. It’s an attitude (see http://www.malotaux.nl/zerodefects). When I started using this concept in projects, defects were hardly produced any more. That’s a very cheap improvement of quality. My experience says it’s not just free: “Quality is Cheaper”.

  3. RevioCTO said:

    Very interesting, Niels. Thanks for the link. I will give this some thought!

  4. lisacrispin said:

    This matches my own experience. Since 2003, my current team has been allowed to manage our own workload, and we’ve been allowed the time we need to develop things in a good way and keep technical debt to a manageable level. We take shortcuts sometimes to help the business folks meet a deadline, but we’re clear what the long-term cost will be and we make sure that shortcut is made right later on. We invested lots of time to learn the business domain and continue to experiment with ways to make sure we understand what the customers need. We took time to automate all our regression tests and we take time for necessary exploratory testing. As a result, it is rare that a ‘bug’ gets out to production.

    We started with lousy, buggy legacy code and tons of technical debt in 2003. I feel any team can do what we’ve done. We were fortunate to have executives smart enough to understand the value of focusing on quality instead of speed, and the need to take time to learn good practices and manage technical debt, but also, we have taken time to push back, as you say, and educate them on how to achieve a great software product.

  5. Bob, thanks for writing so clearly on this. Your take on software complexity has good deal of truth in it. I have seen in many different organisations that it’s easy to create unnecessary complication in software by focusing only on the immediate problem in hand (local optimisation) rather than stepping back and seeing the real, higher-level change needed by a new requirement (global optimisation).

    Often we can take the opportunity to make things simpler when we do this, because rather than 100 special cases and workarounds, we can introduce a pattern or design which deals with all or most of the requirements using just a few rules.

    It does seem difficult for many teams and individuals to take this step backwards and gain perspective, and “lack of motivation” does fit for me as a likely culprit. Understanding, valuing and nurturing that motivation is probably one of the most important things to happen in a software organisation; crucially, appreciating that motivation for software folks is *not* produced by bonuses, pay rises and pressure, but through learning, trust, self-direction (etc.), is fundamental.

  6. Thanks Bob. I was trying to apply your thoughts to my company and I can agree only to some point. What about people with just wrong attitude? People who are totally commited to their work, and are also self-motivated much more than average. Yet they were taught and they believe that bugs happen and that’s just how the work works. It’s even irrelevant to look for them because there will be some defects that would appear only in production environment. They even stopped calling them bugs… They became unfortunate lines of code…

    I’m not saying that I don’t agree with you. I just question the approach that it lack of engagement is always the main root cause of the bugs. It depends on the context (as always).

    • Hi Piotr,

      Thanks for joining the conversation. You mention “people with the wrong attitude”. What would you suggest as the cause(s) of such attitudes?

      – Bob

      • There may be many causes. In the case I was describing there a few of them:
        * lack of good example – nobody showed the people how the quality should be assured and that delivering the product doesn’t end with pushing the change to Version Control System
        * a lot of bad example – for a long time systems were build “over night” and than delivered to the client and then started the “hacking on production” phase (aka stabilization)
        * too strong belief in self-perfection – many programmers I’ve worked with think that what they write is perfect and doesn’t have any mistakes
        * getting bored with delivering a feature – in fact this one is directly connected with lack of commitment

        I’m not sure which of these is the root cause and one more thing I don’t know how to name is taking shortcuts, but not in as much in coding as in other phases of building a product. I’m talking about for example delivering a quick fix without running regression tests and omitting other quality checks, because it was critical bug and it should corrected ASAP.

        Hope that explained a bit more.

  7. Apart from what you mention, what I’ve experienced also is that people-within-certain-roles have certain values. For instance, designers want to create something untangible into tangibility: they value clarity.Developers are creative people who want to create working software from specifications: they value creativity. (That’s why so often developers code in the weekend – when they’re relaxed).
    And what happens when people are pressured (or have the feeling they are pressured): they will prevail acting upon their own values. So then the designer won’t ask again, because he thinks it’s clear. And the developer will accept producing bugs, because he values solving a new puzzle (the creative process) over repairing a bug.
    Only when these people meet with the customer and have some kind of common goal and quality is emphasized, they will adapt their natural, locall optimized behavior .

  8. Lack of motivation can be a root cause, but sometimes there are deeper causes that are leading to that. For instance a lack of understanding by managers of what developers do and need to make good software. Or unclearness of what managers expect from and value in developers. Or too much fear and a lack of trust in the organization.

    Most of the root causes that I see when doing root cause analysis have to do with communication, collaboration, culture, values and feedbback. If these causes are addressed, many problems can be prevented in the future.

    • Hi Ben,

      Thanks for joining the conversation. As I say in the post, motivation (or lack of it) is a system condition. Need we say more?

      – Bob

  9. If we assume that everyone involved in the project _wants_ to be there, and that it is correct to infer from the article that the author is talking about ANY bug (and not just “high” counts, or long turn-around times) then I would suggest that the presence of bugs is actually very good evidence of motivated developers and qa. I mean, if developers weren’t building anything, and QA wasn’t testing anything, then the bug count would be zero (which, amusingly, is the bug count for most of my personal projects) not exactly demonstrative of motivation…

  10. Vernon Richards said:

    Doesn’t this kind of assume we’re all motivated by the same things, in the same way, at the same time?

    Kind of reminds me of when people speak about quality in that it varies for different people.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: