Hi, all.
I don’t understand the technical elements of the good work that Jeff has done here, but it’s a great example of something I have been thinking about.
Whilst work will always be ongoing, to inform our Roadmap (thanks Skyler @minion), something that I think is important, is understanding our ‘Technical Debt’. This term may be familiar to some of you, but it is sometimes misunderstood.
Often, when projects need to make decisions based on factors such as time/ quality/ cost, decisions are made, for the right reasons (at the time), but which with hindsight, could probably have been done differently. The analogy often used, is that of buying a car. A person may need a car, in order to get to work, or to transport the family around. Because the car is essential to them, whether they buy one or not, is not up for debate. If the person can’t afford the car at the time, they may get a car loan. This solves the problem, but obviously leaves the person with debt that they have to pay off.
Technical Debt is similar, and due to decisions that were made in the past, perhaps by others (NixOS?), we need to have an approach for identifying and ‘paying down’ our debt, by improving code/ documentation, etc.
As alluded to in my last sentence, Technical Debt, although tracing its origins back to coding/ software development, is not limited to coding. It could be any element of a project, such as documentation, infrastructure, etc, etc. I was looking for an easy to understand explanation, and this was one of the results I found.
So, ‘food for thought’, do we have any technical debt that we need to manage?
Thanks,
Chris