I was listening to someone talk about software development recently and they used this phrase: “are you collecting toxic waste?”. In this case, they were discussing technical debt, but I found the analogy to be good. I’ve often thought that long term technical debt can make a software project extremely question.
The speaker in this talk had two questions, which I found to be good ones for software developer. The first was are you optimizing individual projects at the expense of longer term technical debt? This is a good way to think about each decision you make about how to build a feature. Asking yourself about short term, or limited scope thinking v longer time thinking is important. Often if we take fifteen minutes and discuss the future of a decision with colleagues, we can better view the trade-off. There are good reasons to sometimes implement something in a short term, fashion, but not every time.
Even if we discuss with ourselves, perhaps by writing down the pros and cons, you might think through your issues. I often find that forcing myself to explain a concept helps me better understand it. It also helps me communicate better with others when I have to work through the issues. Of course, it is very easy to miss something or skip steps when you do this for yourself, I really, really recommend you get feedback from another person.
The second question is are you tracking technical debt or finding ways to pay this down? I think this is one that you need to periodically revisit. Between sprints, maybe after mid length period of time has passed, review the items in your system that you’ve compromised on. Maybe you look at code no one wants to touch, or is afraid to touch. Maybe this is examining inefficient code, which is something that is crucial in a database. While a poor query might suffice with low volumes or data, or limited numbers of executions, this can quickly become a problem, especially as the number of inefficient items grow.
The database suffers from often being a bottleneck, a single place where all clients connect. We often do have powerful systems here, and the platforms like SQL Server make efficient use of resources, but bad code and technical debt become problems. I often find broken code in database that can’t even be executed, and along with poorly written queries, this can hamper future development and flexibility.
Periodically review your code, looking for things to remove or improvements to be made. Your future developer self will thank you.
Steve Jones
Apologies – Podcasts are still iffy with my voice and time. Hopefully after Thanksgiving I get back to them.
Voice of the DBA 