Many of you are too familiar with the following story. It have many versions but the end is always the same. A certain company that invests significant funds in a certain technology, be it a new online service or a software product. They experience awesome success and market proliferation with sales pipeline going through the roof, and huge potential market share. Then a sudden event triggers a chain reaction seismic effect causing the same company to implode and collapse under its own weight. Such event would range in significance anywhere from the release of a new security patch to the lead engineer being hit by a bus. Usually onlookers would immediately blame the event itself as the main culprit, but the reality that this assumption couldn’t be farther from the truth. The actual root cause was some sort of underlying cancer that was eating at the foundation of the building till that event triggered its inevitable demise. It was technical debt.
Technical debt, a familiar term for some and an esoteric term for many, which understanding it would make a world of difference when it comes to executing any IT Project, hence the purpose of this article.
Let me start by saying technical debt is bad debt, the kind of debt that you can not repay nor collect, depending on where you stand from it. It’s a common phenomena when decisions are taken mid life of a technical project to take shortcuts, so it would be possible to save time and resources, deliver and deploy on time, collect milestones, and then it’s someone’s else problem already.
These decisions that lead to technical debt can be something as simple as postponing documentation till delivery is done, writing single-use throw-away code in order to meet a deadline, with a never honored promise to refactor it later, or ignoring an ambiguity in the scope in hopes that it won’t be noticed in user acceptance testing (UAT).
Technical debt can also happen after a project is delivered, live and operational as a service, where certain decisions are taken to execute unsupported workarounds to accommodate for certain business needs but these are usually trivial in nature and they quickly expose themselves after. Say for example someone decides to deploy a change directly to production without testing, the production might become offline for few hours (or days?) then usually the root cause it identified and corrected. You see, the most problematic kinds of technical debt are the ones embedded in a service or product during its delivery as its effects are not immediate yet fundamental, hence more difficult to eradicate and correct not to mention the business impact it causes is very difficult to quantify or limit.
Technical debt is not reserved for non software companies, it can happen to software companies too. In one case I’ve witnessed firsthand a small startup-ish software company that had invested significantly in building a real estate vertical atop of what was known then as Dynamics CRM 4.0. They hired a top notch team to build the solution. As you can imagine, real estate is a very lucrative business so they also had a very good pipeline of sales. That vertical became a hit, yet, somehow the company became defunct for the apparent cause that their key people were poached by competitors. However that wasn’t the real root cause, you see, that team was too busy delivering a product that they had forgone documenting it. The business model was solid, architecture and design was elaborate and yet there was no proof apart from the software itself that the intellectual property (IP) did ever exist. When Dynamics CRM 2011 was released, that company failed to upgrade their real estate vertical solution to the new release, since no one then knew how the solution was structured or had a complete grasp of its intricacies.
Technical debt has a compounded interest as the more you build atop of it the more expensive and complex it becomes to resolve later. As it eventually evolves into some sort of a cancer that spreads everywhere else in the company, sometimes it would become even infectious and start to infect the company’s own customers as they use the affected products and services and integrate them within their own business processes, thus introducing technical debt to themselves as well. So if you are the customer of such company and notice signs of technical debt, then it might be just better to avoid it like the plague as their is no cure for it.
Companies that are riddled with technical debt tend to be political environments where you would face lot’s of change resistance during any software implementation project. As business decisions are driven by existing technical limitations caused by the prevalent technical debt. So it feels more like the business is accommodating the technology not the other way around, as it should be.
Sunken cost bias will be most prevalent obviously in large IT projects, where the business management wishes to at least break even on their investment, let alone making profits. While wherever technical debt is found, it’s an indication of a bad investment. Say for an example an IT project which was not aligned with the strategic goals of the organization due to lack of proper requirements management. This is the kind of project that would lead to more damage than benefits regardless of how much funds were invested in it.
One elusive red flag which is quite harder to catch is when you hear one of the key stakeholders, either on customer or vendor side, saying something like “Let’s not over engineer this!” which loosely translates to “Let’s not do due engineering on this”. Yes it’s a no brainer to keep things simple, but not so simple to the extent it’s void of value.
It’s not difficult to prevent technical debt. By following basic hygiene such as proper scope management, change management and having adequate design reviews, technical debt can be prevented. There are no quick magical solutions and there are no tricks or techniques that lead to avoid doing what should be done to maintain zero technical debt. Yet such activities might appear as of low value, at the time of doing it. While everybody is so eager to write code and build stuff, documentation tend to come last on their priority list. If you ever find yourself on such a project, maybe it would be a good idea to remind the project team of the later inevitable consequences if such apparently low value, only at the time, activities were ignored. As the old adage goes, prevention is better than cure.
Leave a Reply