This nineteenth post in the Making Software Quality Visible series introduces the next major section of the talk. This section explains why we keep having to advocate for software quality and unit testing decades after the importance of both became widely known. In these next few posts, we’ll examine several psychological and cultural factors that are detrimental to software quality.
I’ll update the full Making Software Quality Visible presentation as this series progresses. Feel free to send me feedback, thoughts, or questions via email or by posting them on the LinkedIn announcement corresponding to this post.
Introduction
The previous post explained What Software Quality Is and Why It Matters. Now we need to understand, if software quality is so important, why it’s so often unappreciated and sacrificed.
Automated (especially unit) testing
Why hasn’t it caught on everywhere yet?
- Apple, in January 1992, identified the need to make time for training,
documentation, code review—and unit testing!
At Apple, I found a document from January 1992 specifically identifying the need to make time for training, documentation, code review—and unit testing! That’s not just before Test-Driven Development and the Agile Manifesto, that’s before the World Wide Web!
There are a few reasons why unit testing in particular hasn’t caught on everywhere yet:
-
People think it’s obvious and easy—therefore lower value
Many developers think it’s obvious and easy, and therefore can’t provide much value. -
Many still haven’t seen it done well—or may have seen it done poorly
Many others still haven’t seen it done well, or may have seen it done poorly, leading to the belief that it’s actually harmful. -
There’s always a learning curve involved
For those actually open to the idea, there’s still a learning curve, which they many not have the time to climb. -
Bad perf review if management doesn’t care about testing/internal quality
They may also fear spending time on testing and internal quality will result in a bad performance review if their management doesn’t care about it.
More reasons why unit testing hasn’t caught on everywhere
(This section appears as a footnote in the original.)
Automated Testing—Why Bother? examines a few more reasons. It includes this quote from The Rainbow of Death:
People mostly had no experience with testing outside of the slowness and brittleness of the status quo, and were under constant delivery pressure while feeling intimidated by many of their peers. Who could blame them for not testing when they couldn’t afford the time to learn?
Economists call this “temporal discounting”. Basically, if someone’s presented with an option to push a feature now without tests, or prevent a problem in the future (that may or may not happen) through an investment in testing, they’ll tend to ship and hope for the best. Combined with the fact that the ever-slowing tools made it impossible to reach a state of flow, this combination of immediate pain and slow feedback in pursuit of a distant, unclear benefit made the “right” thing way harder than it needed to be.
On the fear of negative performance reviews
(This section appears as a footnote in the original.)
Automated Testing—Why Bother? also mentions relevant reasons from the social psychology research of Dr. Robert Cialdini. From that talk, in reference to Cialdini’s Influence: The Psychology of Persuasion and Pre-Suasion: A Revolutionary Way to Influence and Persuade:
- Social proof: We follow established norms that we perceive in the behavior of others
- Authority (Authoritah): We permit others to set our priorities and do as we’re told
- Scarcity: We act out of the fear of a closing opportunity window
- Unity: We act in the perceived best interest of others with whom we have a relationship
So if you’re on a team where testing isn’t the norm, and your boss is expecting you to meet a deadline—especially if your feature is critical to the success of the project, and/or you know you have a promotion at stake—you aren’t likely to write automated tests if you haven’t written any before. Whether you feel like writing tests would leave you vulnerable to the wrath of your manager or that of your team, or you haven’t had any interest to begin with, these forces have the effect of reinforcing the status quo.
On the perception that unit testing is easy (i.e., of low value)
(This section appears as a footnote in the original.)
Shortly after joining one team, I presented to my teammates my vision for improved testing adoption across the company and what it would take. One of my teammates said to me in this meeting, “…but unit testing is easy!” Caught off guard, my immediate impulse—which I didn’t catch in time—was to laugh out loud at this statement. I immediately apologized and explained that, yes, it isn’t that hard once you get used to it—but many haven’t yet learned good basic techniques. I summarized some of these in the earlier posts:
- Individual Skills Development
- Code duplication, large changes, and bad excuses
- Legacy code, seams, and the most important design guideline
- The Test Pyramid and the Chain Reaction
- Test Doubles
- Contract/Collaboration Tests and Internal APIs
Of course, my apology meant nothing—the damage was done. This teammate and I never ended up really seeing eye to eye. Per the Crossing the Chasm model covered elsewhere in this series, I moved on rather than continuing to engage with this Laggard.
Have you heard these ones before?
Common excuses for sacrificing unit testing and internal quality
Of course, people give their own reasons for not investing in testing and quality, including the following:
-
Tests don’t ship/internal quality isn’t visible to users (i.e., cost, not investment)
“We don’t ship tests, and users don’t care about internal quality.” Meaning, testing seems like a cost, not an investment. -
“Testing like a user would” is the most important kind of testing
As mentioned before, “Testing like a user would” is considered most important, so investing in smaller tests and internal quality seems unnecessary. -
Straw man: 100% code coverage is bullshit
The straw man that “writing tests to get 100% code coverage is bullshit.” This speaks to a fundamental ignorance about how to write good tests or to use coverage the right way. -
Straw man: Testing is a religion (implying: I’m better than those people)
For some reason, technical people, especially programmers, like to pound their chests as being against so called testing “religion” and those who practice it. It’s a flimsy excuse for trying to score social points by virtue signaling in view of one’s perceived peers. Framing a potentially reasonable discussion of different testing ideas in such a way only serves to shut it down for a superficial, unprofessional ego boost. -
“My code is too hard to test.” (The Snowflake Fallacy)
The common, evidence free “My code is too hard to test” assertion, which I call the Snowflake Fallacy. -
“I don’t have time to test.”
Finally, “I don’t have time to test.” This could be a brush off, or a genuine indication that they don’t know how and can’t spare the time to learn—and management doesn’t care.
On the bullshit characterization of testing as a “religion” or “cult”
(This section appears as a footnote in the original.)
I have to admit, the brief “religion rant” above was inspired by coming across Tim Bray’s Testing in the Twenties. (I found it by way of Martin Fowler’s On the Diverse And Fantastical Shapes of Testing, which I cited in a Test Pyramid footnote.) I strongly agree with the article for the most part (especially the “Coverage data” section), but it shits the bed with the “No religion” comments. I even agree with the main points contained in those comments. However, setting them up in opposition to “religion,” “ideology,” “pedantic arm-waving,” “TDD/BDD faith,” etc., brings an unnecessarily negative emotional charge to the argument. It would be much stronger, and more effective, without them.
Note that Bray’s article is strongly in favor of developers writing effective automated tests. That said, painting people who talk about test doubles and practice TDD as belonging to an irrational tribe (while implying one’s own superiority) is harmful. I’m sorely disappointed that this otherwise magnificent barrel full of wine contains this spoonful of sewage. (A saying I got from the “A Spoonful of Sewage” chapter of Beautiful Code.)
Business as Usual
All these reasons are why Business as Usual persists, as well as the Complexity, Risk, Waste, and Suffering that everyone’s used to. This then allows the Normalization of Deviance to take hold.
Coming up next
This post focused on the beliefs, behaviors, and excuses presented by individual practitioners. The next post in the Making Software Quality Visible series will discuss common organizational antipatterns arising from and reinforcing these individual antipatterns.