Avoiding technical debt should be treated as an insurance

I was going to start this post with a story how JIRA used Velocity 1.4 long after it was dead twice. Not to mention other old and crappy libraries. But having old Velocity was special PITA because I was creating a plugin writing most of HTML in Velocity with a lot of components that should be easily shared between templates and I wasn’t able to use macros and share them across all of the templates.

We could investigate and spent time choosing different template engine but because we had already so much templates in Velocity which we were going to update/refresh only we haven’t made that decision. Probably from a time perspective knowing that the project grew in scope and time we could have made that switch at the start. But who would know?

But that actually made me think about broader issue that actually led to this state - being too much focused on providing the value, and being obsessed on direct return on investment. One of sins that many companies do.

We tell ourselves “if it works doesn’t touch it”, “good is enough”, and so on. We tell ourselves we always need to bring a value to the customer (XP) and so on. And a bunch of other “mottos” that lead to the state in which you don’t do anything that doesn’t provide direct ROI.

That’s a trap. Because if you miss the train it can be too late. Like for example a commercial product using an obsolete, unmaintained by anyone framework, or a library that has a lot of bugs that are solved already in a newer versions but because it would be too much time and risk to upgrade you’re stuck.

It’s easier to upgrade stuff bit by bit at the start of each iteration (just to let it soke in). This way if you’re going to run a big and long running project you actually avoid risk of staying in the back.

By spending now you actually save yourself from big spending in the future. Treat it as insurance.

Go update your dependencies. Don’t let them rot.