Avoiding Technical Bankruptcy

Brick Wall with Text "Until Debt Tear Us Apart"

Matthew "Kerch" Kercheval

10/29/2018

Something always puzzled me, why credit card companies would allow college students to open credit cards accounts. That nice ten dollar combo Phở and Boba Tea for $9.99, ends up ballooning to $50 bucks by senior year. Debt stinks! We have been taught to avoid unnecessary debt; we should take the same care in avoiding technical debt. What is technical debt? What is not, is not a catch phrase because a developer is lazy, or techno-jargon for "I think you feature is ill-advised, and I do not want to do it.". Technical debt is a real thing. Martin Fowler defines it this way. 

 "In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice." (https://martinfowler.com/bliki/TechnicalDebt.html)

Technical bankruptcy is the point at which there is so much technical debt that it becomes virtually impossible to add any new features and resolve defects without significant refactoring. If your team uses the Fibonacci sequence to point stories, it is when a simple task such as adding a new field goes from being a 1 point task, to 2 then two sprints later it is now an 8 pointer. Getting out of bankruptcy is not an easy task, and doing so is the subject of another blog post. However, there are things we can do to prevent us from entering this perils state.

Avoid Unmanaged Debt 

The easiest way to avoid insolvency is not to get into debt in the first place. Adhere to SOLID principals, began to recognize when a design pattern solves an issue we see in the code. Apply the correct design pattern, to solve the issue at hand and not just the one we last discovered. There are times when we may need to develop a feature to take advantage of an opportunity rapidly; we may skip a unit test or two, maybe use a Singleton when a Factory would be more beneficial and flexible. However, this should type of development should be the exception, not the standard operating procedure.

Keep an Accurate Ledger

It is impossible to avoid all technical debt, and like real debt, it is not inherently a bad thing. For instance, buying a home; everyone needs a place to call home. We generally have two choices, rent and buy. There is the third option of continuing to live with our parents, but who wants to maintain SOAP-based services in 2018? We may come to realize, that is a clear benefit to buying a home and to stop paying rent to a landlord. Homeownership allows to build wealth and have almost total control of our dwelling. In this case, taking debt is not a "bad" thing as long we do not buy more hose than we can afford. Likewise, we may come to realize, that it may make sense to stop licensing a piece of software and build our own. More commonly we may be presented with a time-sensitive opportunity, where cost-benefit analysis favors taking on some debt instead of missing an opportunity. 

We cannot escape escaping taking on all technical liabilities; we can track it. Knowing how the big the technical debt is and where it allows us to pay it off promptly without occurring too much interest. As soon, as we recognize we have created debt, add it to the ledger. This ledger should be in your backlog and prioritized inside Kanaban or our sprints. "Knowing is half the battle." 

Let the Spender and Savers Moderate Each Other

Our teams' product owners and scrum master are part of our teams. They are not the holder of the development credit card. The little feature, which seems to have little cost, can quickly balloon, just like that boba tea indulgence on that college credit card. One person should not determine how big or complicated a story is. Nor should we develop software to appease one person, without considering the side-effects. 

Again product owners and scrum masters are part of our teams if they are asking for something, we should not begin our dialog by saying that it is impossible. Instead, I suggest starting with; "we can but, what are we willing to give to do so."

Some of the joys that we have as a developer are solving our user's issues, meeting their needs, and making their lives a little easier. Untamed technical debt prevents us from doing so. If we are vigilant, we can prevent from becoming bankrupt.