Technical debt is one of those things that development teams are aware of but typically put on the back burner to address later. If the project manager and business stakeholders have been informed of the debt it is usually too far over their heads to comprehend. The challenge for project stakeholders is that when they see a working feature they don’t have any deductive evidence that more work needs to be done. Project milestones and deadlines drive the focus on feature development and as such is a high priority in the minds of the business. The hidden danger of technical debt is it can lay dormant even after the initial go-live of the product and reveal itself when the system reaches a new level of usage by users.
Technical Debt As a Strategy
It’s often the case that people think of technical debt as a bad thing and to be avoided as much as possible. While we ideally would like to not have any technical debt the fact is we aren’t always able to build the ideal solution at the time a requirement is known. Project priorities and politics often play a role in the path a development project undertakes. These can be very real priorities that determine if a project is considered successful or not. It could even mean the difference between a project continuing or being canceled. As such we have to deal with these challenges during system development. One way we can cope with changing priorities is with technical debt.
Technical debt can be like a credit card. You can use a credit card and it provides conveniences up front, but sooner or later you have to pay the bill. You may, for example, decide to create a compromise architecture for a particular feature or even an entire system. This could be due to environmental circumstances or project constraints. In these cases, it is extremely important to understand the ramifications of the decisions made to take on technical debt and how you plan to remediate it at a later point in time.
Technical Leads Manage the Debt
Managing technical debt can be challenging on projects where there is no designated technical lead. In my early days when I worked for a partner company that didn’t have a great project delivery strategy. I was assigned to a few of these projects where there was no technical lead. The end result of not having a technical lead was a bunch of functionality that didn’t play well together. Each developer effectively used their own style of coding. If someone like myself was looking at such a codebase I would either make the logical assumption there was no tech lead or they were on drugs during the project.
The way I look at project delivery is the development team members tend to be more focused on features while the technical lead scouts over the entire code base to establish symmetry. Ultimately one person has to own this aspect or the team will naturally attempt to defuse responsibility and no one will take responsibility. The end goal is that the code looks a feels almost as if the same person wrote it, but also the design patterns used by each developer work well in a final product. The last thing we want is for features to end up conflicting with each other and causes poor system performance. In my opinion, the technical lead is the one responsible for understanding and managing debt while also ensuring that the team abides by the same set of coding standards.
Classifying Technical Debt
Some forms of technical debt are more subjective while others are more clear-cut. I’ve found that many developers often create technical debt out of the convenience of completing their task or for not knowing any better. For example, a particular pet peeve I have is when developers hard code entity attributes into their plugins. This lends itself to breakage when the model changes. Another thing that I list as technical debt is when Fetch XML is used in the code base. Fetch being the same as hard-coded SQL makes model assumptions that lend itself to the same type of breakage as hard-coded entity attributes.
There are many other forms of technical debt. You may find that as a consultant, customer IT organizations may have their own classifications and standard to adhere to in your code base. This can add more layers of work that might otherwise be necessary. You may even find that your code must pass a review process before it can be elevated. In which case adhering to such standards may also need to be classified as technical debt.
The Technical Debt Backlog
I came up with the notion of the technical debt backlog when I realized that as the technical lead I had been maintaining my own private list to keep an eye on it. Since technical debt most often is something that comes to bite the business after the fact it would seem prudent to at calling it out in an official manner. Having a technical debt backlog is a way to document the debt item and also allow the team to come up with the best way to address it as part of on-going development work. Short of this, the debt remains in someone’s head which means it has a higher probability of never getting addressed.
This isn’t to say keep a separate backlog of technical debt. You may very well add such things as normal stories within your product backlog. The development team will need to request to bring such stories into the sprint as the product owner may not have enough comprehension of the work to prioritize it with other feature work. The challenge with this strategy, of course, is the political aspects it presents. In less than cordial situations, the technical debt backlog could be used as a means to point a finger or suggest that the quality of work is less than desirable. In these cases, it may be better for the team to maintain such a list in private and bring up backlog items within the stream of the development cycle as items that need to be addressed.
Do What You Need To Do
However you choose to manage your technical debt it is always a good idea for someone to keep an eye on what’s happening in the code base. As I mentioned sometimes political challenges make it less desirable to make this list public. The political aspect often is relevant in consulting project delivery. The goal here ensures it’s actively managed. In projects where the technical debt goes unchecked, it almost always comes back to bite the team and everyone else either before or during go live. For the sake of your sanity and stress levels, I don’t wish this to happen to you or your customers.