Technical Debt can be Handled as Rocks

One of the most controversial topics of engineering is how to handle technical debt. I would like to talk about my opinion on how we can secure the time to work on this.

Technical Debt? Implement the Feature Anyway

Engineers sometimes complain that your manager or business does not understand technical debts. Stakeholders and product managers bringing new ideas to the backlog to expand the sales. Or requesting urgent bug fix to react to premium customers’ complaints.

“All right, I understand the need for re-design. But do we really need to take that now? Now, we are in the critical moment in the business”

You might have the experience to get an opinion like this. Your technical debt cannot be resolved as a result.

There is a time to process while accepting technical debts. If your system release is publicly announced, you would like to meet the deadline no matter what. Or if you have a critical bug fix that can impact our product reputation, we don’t have time to re-design the system.

But we need to be careful to make decisions to defer actions for technical debts. Most of the time is a critical moment in our business. We can release our products as a result if we implement automated tests in the first place. Appropriate activity rather makes the achievement faster like this. Haste makes wastes. Engineers understand this. Stakeholder sometime does not. If that the case, it’s the engineers’ responsibility to push forward. As a professional, you are responsible to stop it if you know that would become problematic. Just like Peter Drucker told in his book, “not knowingly to do harm”, is the basic rule of professional ethics.”

You should not complain that your manager does not understand technical debts.

Big Rocks First

How we can proceed with such an activity which is hardly understood by peoples? Stephen Covey brought us a clue from his book “First Things First”. You can assume that technical debts are like big rocks.

This is the story from his fellow. The fellow brought a jar and bag of rocks and said, “How many of these rocks do you think we can get in the jar?” He put the rocks into the jar. Eventually, the jar was full of rocks. He said, “Is that jar full?” People said “Yes”. Then he brought another bag which is full of sand. He said, “Is that jar full?”. People said “probably not”

This story provides us an idea of how to put the important item into the schedule. We need to put important things into a jar first.

You should not say like “please remove some sands since I need some refactoring”. That will most likely not work. Put your rocks first. Before planning the schedule for new features, you should schedule the refactoring for related systems or implementation of additional tests first. Then new features next.

Should We Talk About Rocks?

One discussion is whether we should talk about “rocks” or not. The jar contains some rocks. However, rocks cannot be found from outsides. It’s just a jar of sands. Should we talk about the truth?

I would like to quote the following from Martin Fowler’s “Refactoring”:

Of course, many managers and customer don’t have the technical awareness to know how code base health impacts productivity. In these cases I give my more controversial advice: Don’t tell!

You don’t have to shut up if your stakeholders understand the needs. However, if they cannot make an appropriate judgment, you do not have to talk about it. If the things get deferred because you talked about, you made your project failed. Sometimes silence can be a part of professionalism. If the jar looks like just sand and everybody can agree that, there is no problem. You don’t have to be awkward as you do that for the success of the project.

You need to be careful managing the stone. Don’t leave the rocks becomes too big to put into the jar. Or you should not put too many rocks at one time. Your stakeholder might complain that there is little sand put into the jar. It’s professional responsibility as an engineer to put rocks continuously while taking balance.