Yesterday, I wrote a teaser about technical debt in NodeBB:
In our specific case, there are other factors that also cause technical debt to incur outside of trying to "move fast and break things". Technologies change, design patterns shift, user expectations are adjusted, or scope is expanded after-the-fact. All of these could cause even a well-designed system to incur some form of technical debt simply due to the fact that you don't know how a given feature will evolve over time.
Our experience with technical debt is similar to others' in many ways, although I feel lucky in that we're able to approach it a lot more differently than others.
Specifically, many definitions speak of technical debt as something incurred in the pursuit of faster results. A trade-off that makes sense at the time due to time constraints.
In our case, technical debt builds most often because we have a single vision for what a feature could be, but do not have the additional context to realize just how that feature could be used in the future.
A contrived example — user groups
A good example of technical debt is the user groups system. When initially conceived, a user group was akin to a Facebook group. A way for users to gather together under a common banner. We later expanded this with the formation of the group badge, which is still in NodeBB today.
What we quickly came to realize was that there were tons of benefits that could be realized with a common user grouping system. Gamification could be tied to user groups, tagging groups of users made sense, and most importantly, privileges could be tied to user groups.
Whenever we ended up in a situation where user groupings made sense, we made use of the pre-existing user groups system. It ended up simplifying a lot of things because we had that groups system that we knew would work predictably. It meant that separate, contained systems need not be re-invented every time you needed to segregate users apart.
The debt? User groups as per the initial design no numeric identifiers. A user has a uid, a topic has a tid, a category has a cid, a post has a pid, you get the idea. So when it came time to create groups, I gave it some thought and decided that group IDs were unnecessary, as the primary identifier would be the group name itself. After all, why would a forum want two groups named the same thing? Madness!
In hindsight, of course, a group ID system would make a lot more sense. It'd make even more sense given that the Write API works almost exclusively on those IDs (groups are the one exception).
We're lucky in that while the debt exists, its impact on day-to-day development is fairly minimal. Other examples of debt are more impactful, but I can't easily think of any because we've addressed a lot of them already!
A hidden benefit of O/SS
A neat little side-benefit of the fact that NodeBB is open-source is that we can choose our priorities more freely as developers. While NodeBB Inc. itself pursues paid contract work and paid support, we often do have time in between paid work to spend time on the core product itself. While the draw is always there to develop new and exciting features, we have fostered an internal developer culture to address technical debt over time, as we consider any ease of maintenance burden is a win that is compounded over time. Likewise, any impactful technical debt often hinders development, and continuing to hack away around technical debt just makes it harder to resolve altogether.
The other part of it is that our source code is open. If we are lazy and take shortcuts, someone will eventually call us out on it. 😓
