Tech debt (big enough to be a mountain) is one of the biggest obstacles in every environment I encounter. Generally this eyesore of tech debt is ignored much the same as the mythical (or not so mythical) junk drawer that can be found in many homes.
But what is tech debt? And the bigger question is why is there so much of this dung heap (tech debt) hanging around? How did there get to be so much of it? The answers may be very hard to swallow. If the answers are hard to swallow, then you have the same problem tech debt.
Has your tech debt taken on nicknames?
Before proceeding to how to resolve the steaming pile of tech debt that is mounding up on your front lawn, let’s examine a psychology related to tech debt that I have been frequently encountering. Truth be told, I actually get a good chuckle out of some of this psychology. Sometimes a hardy laugh is the easiest way to deal with the mound in the first place.
The psychology that I find interesting is the naming of the mound. Not quite to the same level as treating the tech debt as if it were sentient, but very close. This behavior is like giving the bogeyman (or Krampus) a real presence despite it being entirely mythical. Some of my favorite names are less noun and more adjective but they all connotate the same sentiments (laughter and fear).
My favorite name for tech debt is “Hairball”. A hairball is anything that is basically undesirable. Contrary to popular belief, a hairball is not normal. A hairball is an indicator of something being wrong.
If your cat is coughing up hairballs, then your cat has a health issue that needs to be treated. When you have a hairball in the workplace, then you have a major disfunction or distraction that needs to be treated.
If your tech debt is called a hairball, then you have multiple problems. Those problems being that there is disfunction somewhere and also that you know the tech debt is so bad that you have deemed it disgusting and you do not want to touch it if at all possible.
Yuck!
A more common nickname for tech debt
A nickname I have been hearing for well beyond a decade is spaghetti code. The use of spaghetti code is a long running joke – true. Sadly, people frequently make jokes about their tech debt because it is too painful to look at in any other light than with a joke.
If you are calling your tech debt “spaghetti code” you clearly have code that is so confusing, messy, and unmaintainable that you are avoiding it. It costs too much to try and fix anything related to the spaghetti code that it continues to be neglected – until a corporate initiative comes along to replace and overhaul everything. You and I both know that the corporate initiative doesn’t fix the real problem, it just masks it with a new product label.
My favorite nickname for tech debt
My favorite nickname for tech debt (aka legacy code – more on that later) is DIY code. Oh snap! Really? Yes indeed! There is nothing technically wrong with DIY except that usually it means DIW (Did It Wrong). DIY is a means of doing a project on the cheap. Often times, this also means that standards are missed and shortcuts are taken.
Often, the skipping of standards and taking of shortcuts means that there was a knowledge deficiency. Other times, it is just a blatant disregard. And of course, there is the cost of doing the project that frequently pushes decisions to be made to hire the wrong knowledge skillset (cheap labor) or to demand shortcuts be taken (project is taking too long to do it right).
No matter what the reason, there is no reasonable justification to do it wrong. If you take to the DIY model, please understand, there is no replacement for doing it right. Think about it this way, do you want to buy a house where unknown shortcuts were taken that lead to fire hazards? That is not worth the risk. In the same vein, do you want your doctor relying on bad code, where shortcuts were taken, that could help properly determine what is ailing you? Wrong diagnosis could lead to worsening health. Don’t DIY your code!
Legacy
No matter how you name it, “hairball”, “spaghetti code”, “tech debt” or “DIY code”, the result is the same – you are dealing with legacy code that nobody wants to update or maintain. Why? Because the code is piss-poor to awful and evokes day and night terrors. If you are curious, I have heard each of these terms from multiple clients just in the past month. The nicknames and problems are very real!
What is the solution to this problem? As we all know, ignoring the junk code only makes it bigger and more difficult to maintain. Let’s revisit the questions I laid out in the beginning.
What is tech debt?
What is tech debt? This has been answered as we discussed the nicknames. Tech debt is legacy code that is a nightmare to look at and undesirable to work on.
Why is there so much of this dung heap hanging around? There gets to be so much because of many factors. Many of those factors, imo, are laid out in the DIY section. It boils down to people deciding that they just need a minimally viable product to get to market. From there, there is never enough time to fix the crap code.
How did there get to be so much of it? Related to the previous question but this goes a bit deeper to the psychology. Some of it relates to lack of skills. Some of it relates to lack of desire to touch bad code. Maybe some of that fear is that the code is so rickety that touching it would result in serious system outages.
How do we fix it? Truth be told, better decisions need to be made in the beginning. This also goes to ensuring proper skills are in place with the staff responsible for writing the code. Don’t just go with the cheapest alternative on the market. Hire for skills. That will seriously help in reducing the atrocity of tech debt.
What about existing tech debt? You need to make it a corporate initiative to fix this code. Somebody needs to nibble at the code to reduce that debt. In addition, be the champion for your enterprise to make it better!
Put a bow on it
Hairballs and DIY code are an absolute eyesore. There is nothing good that comes from throwing out bad code – even if it is due to the executives demanding a quick to market product. Just because there is success in spite of bad code does not mean it is sustainable.
No environment is devoid of bad code. However, a culture that pushes for improvement and sustainability will continue to thrive. In addition, that environment will be easier to maintain. You must champion the removal of tech debt in your enterprise.
Interested in learning more deep technical information? Check these out!
Want to learn more about your indexes? Try this index maintenance article or this index size article.
This is the first article in the 2021 “12 Days of Christmas” series. For the full list of articles, please visit this page.
Every place I’ve worked has technical debt. I’m currently working for a large state government department. This place has the most technical debt of every place I’ve worked. Perhaps it’s because of the size, I don’t know. Jason, I think you’ve made an excellent point by saying one of the causes of technical debt is the workforce not being skilled to write better software.
But I’m going to add other causes to technical debt. I inherited an old web application which is real spaghetti code. It’s hard to figure out what the original developer was trying to do. This web app has just 10 pages, but it has 12 projects within it. Some call routines from other projects, which call into a third project, which call back to the first project, etc. I have offered, multiple times, to re-write the application, making it simpler. Each time my boss tells me that I, as a software developer, will always say that any project I encounter must be re-written. Therefore, my request to simply turn this project into something more maintainable, is always rejected. My guess is this same reasoning is used by other managers in my organization. Thus, badly written code is never replaced, it only gets added to the pile of other badly written code.
Oh boy. Inertia driven by fear is a huge factor in tech debt. Being shot down on something that can save the company oodles of time, effort and money in the long run is a major pet peeve of mine. I have been shot down for projects that I could quantify the cost of being a measly $2500 only to learn that another project was approved for $150k. Here’s the real kicker, the more costly project ended up costing far more in time and effort of existing staff and didn’t provide any real value to the company. The company was simply afraid of freeing up time of human capital because they were afraid they would lose budget for that capital. I still groan and smh to this day over stupidity such as that.
I prefer calling it “fix the impossible”! There are a couple of contributing factors that have not yet been addressed:
1) Lack of proper documentation, which is usually 🙁 left to the end, and then never done;
2) the work is done by someone who is “smarter” than the rest of the team, not as smart as they think they are, don’t want other messing with their code, so they make it more confusing purposely and, finally, “they are no longer with the organization (usually leaving right after their impossible job is done_)!
Most, if not all, of the tech debt I’ve had to replace has been done by people who consider themselves indispensible/irreplacable. As a contractor, I do not consider myself either, as I will move one sometime, so my primary task, after solving the “impossible” is to MAKE SURE it is understood by anyone who follows me. Documentation is a MUST, as is training the folks I work with (and who will carry on….).
My best example of tech debt was a system (that shall not be named) that was written over 20 years ago in Delphi, and was the “Source of Truth” for a government agency since it was written. It was on autopilot for over 20 years as the author left right after it was operational and went to another country!
That system took only 33 days to understand, document and replace and is now serving well.
Aye yay yay. Ouch!
I love your second bullet item. Too many times have I encountered an architect who declared he was smarter than everybody at MS combined. Sadly those types get it wrong far more often than they get it right. A little humility goes a long way! Not just for self, but that humility can help make the team more efficient and serves a huge benefit to the enterprise.
You’ve got that right! By the way, most of the perpetrators of technical debt work with one technology (which may not be the right one for the enterprise or the problem, and one that very few others know of or understand (and they do all of their work in the one system they learned in school). Best is to use the software/systems in use at the enterprise, and make SURE that it is well understood and used by as many others as possible!