Okay, finally, we’re going to talk about something other than errors. This is the story of how I destroyed $25,000 of company property and got a pat on the back for my efforts.
Or at least, I haven’t been fired.
It’s not clear to me how to describe the code. Maybe this?
It’s hard to portray “I deleted 1,700 lines of code.” But that’s what I did: I deleted 1,700 lines of code. So here’s the story: Once upon a time, before I was on the project, we were planning on doing I/O using a particular hardware block. So a developer spent a month writing up some code to interact with it, tested it, got it submitted. Multiple classes, designed to interact with an array of hardware.
Of course, you know how this story ends. We decided not to go forward with using those particular hardware modules. And, in some sense, that’s fine - requirements change over the course of a project. I’m sure I have a sister blog in project management talking about this scenario from the project management side.
But this is programming for maintainability, and the code stayed. It stayed for a year. It came to my attention because one of our tech leads made a pull request moving it from our internal development branch to our external branch in preparation for releasing our product as a whole.
As a reviewer, it’s not often that I can use my ban hammer on a review and say “you should just delete all this code,” but it’s fun when I can. It’s easy to assume that code in a codebase serves a purpose - after all, somebody spent cash money to have it made, and who are you to question their wisdom? Be it a function that appears unused, a header that’s unreferenced, or even an entire library that nobody seems to use, you can just delete it. In this case, keeping it cost a senior engineer a day to pull the code to another branch, test to make sure it works, post it for review, as well as my time to look at it.
“But wait!” you say “what about this one little utility function, nobody uses it today but what if somebody wants to concatenate ‘pickle’ to a string in the future?”
Well, I say, are you planning to concatenate “pickle” to a lot of strings? If your best plan for the function is “well, maybe someday in the future…” then I’m just going to cut you off. How much would it cost to rewrite concatPickle()
, or pull it from source control history? If you kept it, how much does it cost - in maintaining testPickle
, in junior engineers asking why you have a seemingly unused concatPickle()
function, in updating concatPicle()
to use the newer standard library std::concatPickle()
function? Code isn’t free to write, and it isn’t free to keep either.
So now, next time you see that function that you keep around “just in case we ever need it”? Marie Kondo it.
This blog series updates every week at Programming for Maintainability