Or do they?
And who are they, anyway, and who are we?
The phrase, “They don’t pay us to write tests,” comes up from time to time in conversations, in articles, in blog posts, in conference talks, and so forth. What does it mean?
Contemporary software development methods typically include writing executable tests of one form or another, for one purpose or another, at one point or another in the development process. The title phrase reminds us that our customers / managers / stakeholders / users do not explicitly ask us to write these tests, just as they don’t explicitly ask us to perform any other activities we might deem appropriate as professionals.
“They” just ask for the end result “they” want. The details of how we achieve that result are not interesting to them…indeed, in most cases “they” wouldn’t even understand those details. It isn’t their job. It’s ours.
Some developers use the phrase as an excuse to avoid writing executable tests. They don’t understand the value and they’d rather not expend the effort. Many will suggest that writing such tests adds time to the development process. (Hint: It doesn’t.)
Other developers use the phrase as a reminder that we should spend as much of our time as we can adding value to the product-in-development, and minimize the time we spend on supportive activities, such as writing executable tests. We should think about which tests are really helpful, and avoid writing numerous test cases of little or no value.
In my view, the second group of developers is on the right track. We want to minimize the time and cost of Type 1 Muda in our process. Type 1 Muda is appropriate when it’s the only or best way we know (or have access to) to get the product built right. Even then, we don’t want to devote excessive time to it. We want to maximize value-add time.
For more of my brilliant (sic) opinions on the subject, see the blog posts Institutionalized Workarounds and What’s our focus for improvement?
Although the phrase offers useful advice to those who understand it properly, I think it leads to problems.
Problem #1: Are we order-takers or professionals?
There’s an odd thing about software developer culture. On one hand, developers insist they are professionals who know best how to perform their work, and on the other hand, the same developers often complain that managers or stakeholders won’t “let them” do the right things in their work – such as writing executable tests.
The phrase, “They don’t pay us to write tests,” can be understood naively to mean that unless our stakeholders explicitly ask us to write tests, we shouldn’t write them. If that’s the case, then we’re just order-takers. Maybe some are comfortable with that, since it absolves them of professional responsibility.
They should consider whether they would like to live on the salary of an order-taker instead of a professional. The pay incentives for choosing the software field are based on the assumption we’re professionals. You can’t have your cake and eat it, too. If you just want to be an order-taker, no problem – many employers will be happy to pay you accordingly.
Problem #2: Does the first group of developers understand what the second group means?
Unless and until someone invents a better way to ensure software products do more-or-less what they’re intended to do, we’re stuck with writing tests. It’s part of the process. If we’re professionals, it’s part of the process that we define. Of course, if we’re just order-takers, then…well, just skip the rest of the post.
The first group of developers – the ones who don’t understand the value of testing or checking the code – are unlikely to understand what the second group means when they say, “They don’t pay us to write tests.” They’re likely to take it as an excuse not to check the functionality of the code.
That’s been my observation in the field for many years. I think it’s one of the causes of the generally low quality of software in the world today.
A couple of humble suggestions
I have a suggestion for the first group of developers. Learn principles of software engineering and start applying them. Stop arguing against good practices just because you weren’t taught them in school. Schools lag behind industry in such matters.
Stop claiming well-known good practices that have been in use for decades are “new” or “unproven.” They are older than you are. They are proven. It would take you less time to learn those practices than you’ve already wasted arguing against them. If you still don’t like to use certain practices after you’ve learned how, then at least you will be acting from an informed position.
I have a suggestion for the second group of developers, too. Stop saying, “They don’t pay us to write tests.” I suggest this not because you’re wrong – you’re not wrong, you’re right. The problem is your target audience lacks the frame of reference to understand what you mean by that phrase. It’s too easy for them to blow off testing altogether, and to say “But Big Shot Technical Coach says we don’t need to test anything.”
Just a thought.