Many of us know that reducing financial debt in our lives leads to a bit more security in our minds. We are better able to cope with unexpected expenses when we have the ability to get credit or pay for something in cash. If you've ever had a major house repair, car calamity, or (hopefully not) medical issue, you know what I mean. At least in the US. That last one is less of an issue in many other countries.

We know that our code has technical debt, and often we fight a battle with project managers and business people over whether we should spend time paying down that technical debt or developing new features. We certainly can do both, but often that's not a choice we are given. If we do get the chance to reduce technical debt, it's a tiny fraction of the time that is allocated to adding something new.

There might be a better argument for reducing some technical debt: security. There's an article that talks about the security risk posed by moving too fast and not ensuring there is rigorous security testing. This is a common problem in many companies that adopt some parts of DevOps, but forget that quickly deploying new code isn't the only principle. We also need to learn from our mistakes and quickly correct them.

I am a big fan of releasing often, especially for security purposes, but those releases need to build on each other with not only new code but refactored old code that doesn't perform well or has a security issue. More importantly, we need to ensure when we find issues in code, that all developers are aware of the problem and don't repeat the issue. We also need to update our testing to ensure that humans don't continue to write code in a style that causes known issues. We want to avoid antipatterns in our code.

This is less of a developer issue than a managerial one. The C-suite and all management that are involved in software need to prioritize security so that known issues are fixed quickly. This also should involve ensuring that technical debt is kept under control as a lot of this poorly written code increases the chances that a vulnerability is in the code. Either because the code isn't well written or because developers avoid touching the code in the future.

The best solutions, to me, involve DevOps. Make small changes, deploy them, instrument them, and learn if they work well. If not, fix them quickly. While this might end up delaying some features, ultimately it ensures that our software is in better shape, with a reduced risk of simple security mistakes upsetting our customers.