Sam Heuck

Why clean code matters

I'm going to give you two crucial pieces of information, and I want you to answer one very simple question based on this information.

1: The name of a file:

2: This file is a cronjob

The question is, how often does this job run?

If you thought to yourself, I don't know yet, you might be a developer. If you are a normal human being, you thought, That job runs every hour. You normal people would be dead wrong, but certainly by no fault of your own. No, the blame lies with the developer, who made the seemingly innocuous decision to name this job based on the frequency with which it runs. This job actually runs every 2 minutes. So why is it called hourly sync? Why, when the frequency at which the job needed to run, was the name of the job not changed to match?

The only true constant in software development, the only thing you can count on happening every time, on every project, is change. This job was once actually run every hour. But as the user base for the application grew, hourly was not frequent enough to keep things... synced. So the cadence was increased, but the name of the job could not be changed, for fear of breaking the calling code.

It is for this reason, the fact that change always rears its head, that developers want to write clean code. It is why we cling to principles like DRY, single responsibility, encapsulation, inversion of control, and open closed. So when a change request comes in, you can say, "yeah that's easy" instead of, "this might break other things, I'll need a few days to sort this out".

So invest in refactoring. Invest in solution architecture. Yes, in some cases, you may violate the 80/20 rule, but believe me, when that inevitable change comes around, you'll be glad you did.