by Cesare Rocchi

Weekly cleanup

by Cesare Rocchi

Tags: development

Do you clean your office once a week? Or somebody does it for you? Do you shower once a day (more or less)? Do you trim your nails periodically? How often do you clean/update the dependencies in your software projects?

Every guru solopreneur would likely tell you that, instead of doing “work that nobody notices”, you should grind, do more marketing, grow your audience and sell more.

And yet, if nobody takes care of your code base, it will decay. How fast? That depends on the dependencies you picked.

There’s still web apps running on Ruby 1.9.3-p551. It’s been deprecated for years and it doesn’t even receive updates for critical security issues. The same happens in pretty much any other ecosystem. Try compiling a Swift 2 project with Xcode 10.1 :-p

Some open source projects even publish a versioning policy, that will help you with planning upgrades. I particularly like the ones of PostgreSQL and Ubuntu, which are two of the workhorses I base my products on.

When it comes to keeping a code base up to date the two extremes are:

  • keep it running as long as you can, touch it as little as possible. When the situation gets unbearable upgrade (and potentially go through a lot of pain).
  • follow the evolution of dependencies as closely as possible. Integrate a new (stable) version of a gem/module/library as soon as possible. Essentially, spread the pain of upgrading along the way instead of absorbing it all at once.

A few months ago I started getting closer and closer to the latter approach. So far it payed off. At first it was quite demanding because some new dependencies introduced breaking changes. Then it became a habit and now I do it once a week.

It’s usually a matter of running a gem|pod outdated, picking one item, updating a reference and running tests. I can do it even when I am tired, as it’s not a cognitively demanding task usually. If it’s all green, I push to production. If it’s red, I assess the effort needed. Small? Do it now. Big? Schedule it.

Will my customers notice such a change? Likely no, although sometimes a new version of a library can be more performant. Will I feel better? Yes, because:

  • the intimidating feeling of a big upgrade is gone
  • adding new features will be easier

I consider a code base a bit like a plant. If you don’t take care of it, it will eventually perish.

No, the moral of the story is NOT that you can skimp on marketing.