Time for improvement
Today I had a long discussion – more of a one-sided rant, really – where I tried to convince two other programmers that quality stems from the programmer, and almost every programmer has it in their power to change things for the better.
Suppose you are given the task, of say, implementing a Frobnitzer for the next minor version of Blooperator. You open your editor and dive in to gain understanding on how to best implement the feature. Then you get that sinking feeling. The existing code was intended for a Flubbergleep instead. It was written by someone who left the company ages ago. It’s poorly documented. Worst of all, it looks like a mess. You sigh, and wish for the 307th time that the customer would agree to The Big Refactoring.
But nobody ever pays for refactoring only. And why should they?
Clean code is a nice thing to have, but from the customer’s standpoint, that’s not what provides the value. The customer just wants their Frobnitzer. While the existing code is ugly, with lots of tight coupling, obscure variable names and near-indecipherable methods, it works as expected.
You are a programmer. Your job is to solve problems for the business, even if they don’t acknowledge them.
Poor quality code is a problem. So solve it.
It doesn’t really require The Big Refactoring, even though it would be the easy way to do it. When you work out what that complex algorithm with lots of one-letter variable names is actually doing, clarify the variable names. When you’re forced to change a method that consists of 200 lines of arrowhead code, flatten it. If you can extract a method to clarify the meaning of the code, do it. There are automated tools that can do it and verify that they don’t make any semantic changes to your code. Use them — make any and every simplifying or clarifying change you judge safe enough to do while still shipping on schedule.
If you can, write tests for it. So you’ve got a 100kLOC project with zero tests, and seeing the first one throw a red bar is a bit disheartening. Grit your teeth, make it pass, then go for another one. In a week you’ll have a couple of dozen. In a month or so, you’ll probably surpass a hundred. And the next maintainer will thank you.
Most likely that maintainer will be you.
If it feels like you can’t write tests for it, I’ve got a book you need to read. Get used to the idea of working with legacy code. You’ll be doing that most of the time anyway.
Complaining endlessly about how you’re never explicitly given the time and resources to get things right is a cop-out. Making things better bit by bit is rarely easy, rarely rewarding and almost never appreciated by the customer. But it’s the right thing to do.
So quit complaining, and go do your job.