Yep. Or in other words, you (usually) can’t solve cultural problems with technical solutions. If your team culture doesn’t value long term thinking, it’ll take more than a schedule change to introduce that mentality.
In the story in this post, one important thing that happened was that the team (with management) came together to acknowledge the tech debt problem, acknowledge they want to solve it and talk through potential solutions. This moves the problem from something individuals care about to something the team as a whole acknowledges it care about (a shift from individual knowledge to common knowledge). Once everyone agrees this is a problem, individual engineers will know they’re acting against the will of the tribe by writing lazy pull requests. And being reprimanded by their coworkers for doing so will have much more weight.
> Or in other words, you (usually) can’t solve cultural problems with technical solutions.
Yes, though technical solutions go a long way towards making cultural solutions work and stick.
Eg running your tests automatically when someone makes a Pull Request is much more robust, even in a cultural sense, than asking developers to manually run the tests.
Technical solutions can help make the culturally favoured approach also be the path-of-least resistance.
Of course, you still have to write the tests. (Though even there, you can make your technical tools check for eg test coverage. That can be gamed, but that's more effort than when you can just ignore it; and even gamed coverage is better than no coverage.)
True; but you're going to get much better testing if your team collectively cares about it than if it feels externally mandated by that one annoying guy who set up your commit rules.
Technical solutions are the best solutions when they work. But being technologists will bias us towards looking for technological ways to solve problems. Its not always the best approach. A few hours chatting over lunch is usually a much more effective way to change how your team works.
> True; but you're going to get much better testing if your team collectively cares about it than if it feels externally mandated by that one annoying guy who set up your commit rules.
Some of the worst tests I've ever seen were in places where managers measured test coverage. Reams and reams of absolutely useless tests that may not have checked anything that mattered, but that did bump the coverage metric up.
Reams and reams of absolutely useless tests that may not have
checked anything that mattered, but that did bump the coverage
metric up.
I would go farther than that, and call those tests worse than useless. Tests that are written to appease some kind of automated coverage metric god tend to be tests that test internal implementations rather than API contracts. So you end up with a codebase where a single line change to production code requires something like 150 lines of test code changes, all because the internal representation of some data was changed in some kind of trivial way.
It's possible to avoid this failure mode, but the teams that are smart enough to avoid this failure mode are also generally smart enough to avoid having unreasonable coverage goals.
In the story in this post, one important thing that happened was that the team (with management) came together to acknowledge the tech debt problem, acknowledge they want to solve it and talk through potential solutions. This moves the problem from something individuals care about to something the team as a whole acknowledges it care about (a shift from individual knowledge to common knowledge). Once everyone agrees this is a problem, individual engineers will know they’re acting against the will of the tribe by writing lazy pull requests. And being reprimanded by their coworkers for doing so will have much more weight.