Log4j and new software projects.
I was not affected by the Log4j bug in any of my professional or personal projects. But, I still understand why the impact of it is far reaching and why vulnerabilities will persist for years. And that is because tech debt is not something which most companies invest in.
Consequently, this is why I will not start a new project on an old framework.
Are new projects immune? Not at all. But, if that is your metric, then you are missing the point.
Almost all modern pieces of software are large enough to depend on multiple 1st and 3rd party projects. And many of those have dependencies of their own. And while most companies are smart enough to filter out dependencies based on which ones are and are not actively being worked on, if you start with an older version, you increase your odds that if you are forced to update, that you will be forced to update FAR more than just one library. You also increase the odds of breaking changes in just that one library. Not to mention the others.
In fact, you likely just need to ask yourself "why are we even considering older frameworks/dependencies in the first place?". And the answer is probably because it is perceived ALREADY to be too costly to adopt a new version.
And, if you can't justify moving forward at the start of a project, how do you think it will be perceived when a critical bug pops up years into development?
Tech debt with regards to remaining up to date on dependencies is something that grows in a more logarithmic or exponential fashion the further you fall behind. Adopting something old from the start basically means adopting an attitude of not maintaining your software properly.
So, my mentality over the years has been to:
- Never start a new project with old dependencies just because it might seem easier, and
- Invest as much time and effort up front as possible in maintaining and up to date set of dependencies. Even build processes around it where possible.
Comments
Post a Comment