I’ve heard it said a lot of times that “users don’t care about code“. Along with things like “perfect is the enemy of the good”, this saying falls under the category of technically true, but unhelpful.
In order to understand why this saying is harmful, let’s dissect it. When people say “users don’t care about code”, what’s the meaning behind it? Here’s what I think they’re trying to communicate:
Jason, don’t waste time perfecting the code, which users won’t ever see. Users don’t care how clean or modular or whatever your code is. User only care that the product does what they need it to do. So please, be reasonable. Focus on the part of the work that really matters.
On the surface this appeal seems totally reasonable. Stop polishing that code for the 15th time, Jason! We need to move, we need to ship!
But like I’ve said elsewhere, the general danger in coding is not that developers spend way too much time gold-plating the code. A far bigger problem in the industry is that developers rush their work and do a shit job that paints them tighter and tighter into a corner until they literally aren’t able to ship features anymore.
I’ve seen teams get close to this point. In 2016-2017 I worked with a team that theoretically released to production once a month. However, their codebase was so fragile that every time new code was written, the new code broke existing features. Plus the new code itself usually didn’t work right. QA would find bugs and the development team would have to revisit their features. So the release would get delayed. And delayed. And delayed. Frustration would mount. Finally the release would go out, two weeks late, and now the dev team would be under increasing pressure to deliver the next chunk of work in less time. So what would the developers do? Same thing everyone always does, which is cut corners to get the job done on schedule. This would of course further exacerbate the problem and the next release would take even longer.
What caused these delayed releases and fragile features? Bad code. Did the users care about the delayed releases and fragile features? Yes, these issues had an acute negative impact on users and all throughout the organization I was working for.
So yes, it’s true that users don’t literally care about actual code. But when your code is so shitty that your product is full of bugs and you can’t get a release out to save your life, users care about that.
What this has to do with testing
If a developer or manager believes that users don’t care about code, he or she probably also believes that users don’t care about test coverage.
And in the same sense that it’s technically true that users don’t care about code, it is technically true that users don’t care about tests.
When a dev team is under pressure to release a feature, what’s usually the first thing to go? Tests, of course. I can’t count how many times I’ve heard somebody say something like, “We would have written tests but we wanted to get something out quickly.” It’s commonly believed that skipping tests saves time but except for the most trivial features it’s usually a lot more time-consuming to test features manually. Like every other form of cutting corners, skipping tests creates technical debt and makes our work harder.
Cutting corners and consciously incurring technical debt doesn’t just make our work harder at some abstract distant time in the future. Technical debt costs technical interest. Those interest payments typically start being due immediately. And the more technical debt we have, the slower and less reliably we’re able to deliver value to users.
So please don’t tell developers that users don’t care about code as a way to encourage “speed”. Poorly-written code does affect users.