Weekly Rant: Linter Madness
This post is part of the “Weekly Rant” series
Static analysis is great to have in your tool belt. I jumped on that boat pretty early, reveling in metrics from copy-paste-detection, cyclomatic complexity, and stability vs abstractness quantification, and even adherence to architectural constraints not enforced by the language (e.g. “modules” without build- or runtime constraints). Most people were happy to hop on that boat with me when given the chance, taking comfort in the external validation that a set of opinionated linter provides.
But static analysis can’t do much more than establish a baseline. This is what I’ve seen over and over again: conventions are established, static analysis enforces some quality metrics, and no-one really reviews anymore. “If it’s good enough for the linters, it’s good enough for me”.
Instead of trying to address that mentality I’ve been guilty of adding more linters, testing more things. At some point you really run into the limits of what linters can enforce while the benefits become more debatable, and while having done nothing about the real problem: rubber stamping. Also the more linting you add, the higher you put that bar, the more likely developers will stop thinking for themselves. Our linting is so sophisticated, after all. The code coverage says 100%, all conventions adhered to, what is there left to look at?
That’s a common pitfall I’ve observed. The only thing worse would be to do no linting at all.
The next part is only a single anecdote but it really stuck with me. Around 2015 somewhere a PO pleaded with me to come up with a single metric, because he desperately needed to show management what the teams were spending all their time on. The mortal sin here was of course framing refactoring as work distinct from feature development and not as a part of the development process. I don’t remember why I didn’t just tell him that. It is etched in my mind from a student question in my Scrum master training as early as 2010. That was my first mistake, I guess.
I tried to explain to him that whatever I would come up with here, would be pulled out of thin air. He didn’t care. As long as we can show a number that goes up, he said. I should have flat out refused. Second mistake. Instead, I subjectively assigned some weights to different metrics, did some scaling, et voila: a single metric. I wrote a 10 page document explaining all the decisions made and detailing the weighted aggregation function. No-one read it.
It’s not hard to predict what came next. Development became for a large part focused on making sure this metric I pulled out of my shiny metal behind, showed an upward trend. Even less time was spent on short term realization of features and software rot was not really halted. It didn’t take long for this “single metric” to just be dropped and the PO to push back on anything that had any mention of the word “refactoring”.
Some may argue that my “fitness function” was not correct. And they’re probably right. But it was not just that, also the available metrics were probably not sufficient to really drive decision making. It would have required many iterations, months of validating, to get it close to “right”. All the while the “management” would question our re-evaluation of measurements and weights as “cooking the books”. They were not looking for a steering mechanism. They were looking for a validation mechanism.
This is a very long winded way of saying: use static analysis wisely, kids.