You might have noticed that for a while now technical debt has been on the lips of everyone. Do you believe that your organization is lacking technical debt? Are your competitors shadowing over you with their mountains of technical debt? Have you been searching for a quick fix to ramp up your technical debt creation?
Illustration by Maria Niemi
If the answer is yes, look no further! Here are 6 easy tricks to help you to generate magnitudes of technical debt faster and easier than you ever believed to be possible!
Step 1) Write tests “later”
This is the most basic trick for skyrocketing the technical debt creation in your organization. Yet some organizations still have not embraced this method.
Start by establishing a sense of urgency. Fueled by this urgency proceed to convince your team that there is no time to write tests “Right Now”. The key to success for this selling point is to paint a picture of a less urgent tomorrow, where the tests can be added to the codebase.
Not only will this create a metric ton of technical debt, as a bonus you may be able to create an illusion of hitting the market faster with your product.
Step 2) Forget Planning
The second step is to forget about planning for the rest of your life, because that is 100% what Agile is all about. Forgetting. Planning. Planning is expensive, and organization’s resources should not be wasted on something that can easily be skipped with the newest methodologies.
Since Agile allows us to skip planning, we need to embrace it fanatically. Agile is all about creating new features for customers without planning ahead. The key is to have as many features possible in production with as little planning as possible. Agile is purely a numbers game. More is more, thus there is no reason to rework on something that has been deployed already.
The takeaway is to remember that back in the Waterfall days technical debt did not exist yet, so we want to avoid falling back to that time with all costs.
Take agile seriously. Forget. Planning.
If someone in your organization tries to bring planning to Agile, you need to get rid of such heretic before they can spread their false beliefs.
Step 3) No more safe spaces
Technical debt grows the best in shadows and when left alone. Some could even claim that technical debt has an interest rate, so slowly but steadily it increases by itself. Because of this, we need to give it time and space to accumulate. One of the most dangerous things you can expose your technical debt is… Well, being exposed.
We want to protect our technical debt from unnecessary attention. Since we worked so hard to cultivate it, it would be a shame if it would be exposed before growing big as a mountain.
The strongest way to protect our technical debt is by introducing a strict “Shoot the Messenger” culture to your organization. If it is repeatedly made clear by example that shedding light on existing issues is really bad for an individual’s career, it is safe to assume that future whistleblowers think twice before speaking their mind. This is a great method for establishing dominance over your team, as well as keeping snitches at bay.
Step 4) Permanent Hurry a.k.a. Eternal Death March
Since we already created a sense of urgency, we are now able to ride that wave all the way to the never-ending grind.
The key for this to have a minimum of 5 extra tickets added to each sprint, to ensure that the developers will have enough work at all times. It is a well-known fact, that when all the tickets on the sprint are completed, developers will cease working completely. In order to avoid this standstill, we will always have to make sure that there is an absolute minimum of at least 5 extra tickets on the sprint. Naturally more the merrier is the rule of thumb here. It is pretty much a grounded fact there cannot be too many tickets on a single sprint.
Illustration by Maria Niemi
Remember: If all the tickets on sprint were completed before the midnight preceding the sprint review/demos, the project manager has failed as a supervisor. If the tickets are NOT completed by the same deadline, the developers have been slacking and should face serious consequences for doing so.
By pushing the developers to their mental and physiological capacity, we will ensure that all the corners that can be cut will be cut. By running on the tighest possible schedule, there will be no time for refactorings, ad hoc improvements, or god forbid planning of any kind. This will lay the groundwork for all of the technical debt that you wish to accumulate.
Step 5) All the work has to be ticketed
No refactoring without tickets. Period.
Under no circumstances should it be allowed for developers to do any sort of ad hoc refactoring. If you hear your team using slurs like “See it, fix it”, you might be already in dealing with this undesired behavior.
It should be made crystal clear for the whole organization, that working on anything that is not ticketed, approved, and appointed by the project management, is strictly forbidden. It should be clarified doing so is a form of time theft, and thus will be dealt with as such.
You don’t allow watching Netflix at work, so why would you allow any other form of time thievery. Right?
Step 6) Avoid tooling
Many programmers are inherently lazy. Thus they are always working towards spending company time, money, and resources into reducing their own workloads. They call this non-sense “Tooling”.
This so-called tooling comes in many forms and shapes. Starting from code formating tools all the way to expensive dedicated build servers, pipelines, and other massive money drains. What these instruments have in common is their purpose. To make developers look like they are working, when in reality they are making the computers work in their behalf..
Tooling is said to reduce technical debt in many ways. Standardizing development environments, shortening cycle times, enforcing coding practices and improving test coverage to mention few. The developers with interest towards the so-called Dev(Sec)Ops culture are especially dangerous to your technical debt with their vicious plans. They often act as advocates towards spending resources in tooling instead of valuable customer features.
Tooling can easily be seen as a way for developers to reduce their workloads, so it is often safe to argue and push for them to work on such things only on their personal time. After all, why should the company sponsor something that makes employees work less?
Conclusion
All of the pre-mentioned steps support and empower each other, so you should act quickly in case you have not yet implemented some of them. You will surely notice that implementing these methods will rapidly increase your technical debt. No longer will you be envious of mountains of technical debt possessed by your rivals.
As a word of warning though, it might be smart to somehow control the debt. Some critics have mentioned that having too much technical debt might bankrupt the whole operation. Thus it is advisable to allow some light shedding of technical debt. This way you can boast with truly crippling quantities of technical debt without fully bankrupting the organization.
Remember, a bankrupt company cannot have technical debt at all.
