Dependency Based Tech Debt

One of the things I am doing right now is ripping Bootstrap out of App-o-Mat. The site was mostly built in 2013 and at the time, Bootstrap was good about hiding all the float/clear/positioning nonsense from CSS and giving you a simple grid system. Once I had it, I used everything else it brought along. The site markup is pretty coupled to Bootstrap.

My plan is to build it on just a very small amount of hand-written CSS. Modern CSS has flex and grid layouts built-in, and so re-implementing what Bootstrap offered for layout is not that hard (especially for my limited usage).

When I’m done, my only frontend dependency will be on highlight.js, which syntax colors my code samples.

Ripping out dependencies is a recurring theme for me when a codebase starts to age. I wrote about this in Tech Debt Happens to You.

And I think that this is the main source of tech debt, not intentional debt that you take on or the debt you accumulate from cutting corners due to time constraints. The debt that comes with dependency and environment changes.

Being able to bring code into your project or build on a framework is probably the only thing that makes modern programming possible, but like mortgages, they come with constant interest payments and a looming balloon payment at some point. 

There are some you can’t avoid, like the OS, language, and probably database, but as you go down the dependency list, remember to factor in the debt they inevitably bring with them.

Of course, in 2013, the trade-off was probably right for me. I really didn’t want to build anything complex with CSS as it existed. Today, I be hard-pressed to take on any CSS framework dependency (I looked at Tailwind).

It’s not that they aren’t useful—it’s that I don’t have time to keep up with the dependency management problem they will bring with them, and they don’t promise any kind of long-term backwards compatibility (like SQLite does, for example).