Avoiding Future Technical Debt Building IT Solutions

Simplicity is the name of the game! That is rule number one in building future proof debt free information technology solutions. The more sophisticated your solution is, the more potential that it will become an absolute technical debt in the near or far future.

Origins of Technical Debt

There are three main origins of an information technology solution to turn into technical debt either in a near future or the far future. The two cases differ a bit in terms of design and decision making considerations.

1. The first and most influential cause is evolutionary and innovative changes in technologies used: since the ages of first computers technology evolves every day, some evolutionary changes are enhancements that bring better performance to applications such as increasing CPU frequency, increasing processing units internal and external cache memory, and adding more RAM to a system. Yet, some evolutionary changes brought levels of complexity that affected IT solutions from a software point of view as well as hardware infrastructure. Example are multi-threaded CPU cores, high speed networks, security appliances, and more. The contribution of technology changes is not limited to hardware architecture and extends to software technologies as well, for example the evolution of Java virtual machine (JVM) version had ever brought enhancements as well as problems of deprecated functionality. Programming languages also evolved along with embedded libraries being used.
2. The second cause lays down in the mindset and mentality of software and infrastructure architects and designers as well as senior technology leads who intend to build a Concord supersonic multi-mach speed aircraft while they only need to build a C5 single engine to serve the purpose. Instead of sticking to what is actually needed at the time of building a solution, architects, designers, and IT leads tend to over exaggerate taking into consideration futuristic potentials of might be needed functionality and behaviors of a solution. This brings undesired complexity and adds more to potential technical debt.
3. Businesses illusive cost efficiency asking for more functionality than actually needed: some business owners think that if they can inject as much as they can within a purchased solution at the optimal price that would be a gain in terms of cost versus value, while on the ground only 40% - 60% of that injected functionality is being used. Definitely, this is common behavior in many regions of the world where evaluators of a solution tend to count features against total cost of ownership of a solution.

How To Avoid Potential Futuristic Technical Debt?

The solution to avoiding potential futuristic technical debt lays in taking into consideration the main three causes that are expected to result in technical debt. The ides is to treat these reasons as risks and try to apply one of the risk management strategies on them: forbid, mitigate, or accept.

Technology Changes

Although technology is changing every day, there are things that shall remain constant within an evolving technology. For example using Intel's CPU based instruction sets had evolved vastly between days of x8080 processors and todays Xeon scalable processors, yet most of the applications running today are limited to the range of instruction sets laying between x80286 and Pentium processors. Other than operating systems, artificial intelligence, machine learning, and gaming industries, most of software domains are strict to a limited range of instruction sets.

Designing applications for multi-threaded CPUs, high speed networks, and sophisticated security infrastructures might require adequate attention at times of design of a solution.

Considering potential changes in future versions of runtime and libraries used is by its own technical debt that can be taken as a fact with risk probability of near 100% and an impact of 8 on a scale of 0 to 10. The best mitigation approach is to always consider long-term support (LTS) versions as much as possible.

Architect Mindset Modes

As a solution architect, I adopt three modes of mindset: present, near future, and far future mindsets.

With the present mindset mode, I try to consider the exact needs and requirements of a solution that covers unleashed business and technical requirements. I try - as much as I can - to avoid adding extra complexity aiming to the future as far as it is not required within the scope of the current needs.

Switching to a near future mindset, I always focus on potential changes and normal evolutions in technologies used between project initiation, go live, and first year of production runtime support. This includes considering current LTS remaining time and potentially launched new LTS within that timeframe.

I only switch to far future mindset in terms of strategy setting, elimination, and product after lifetime decisions.

Business Owner Attitude and Expectations

As much as possible try to limit injections produced by business owners by imposing a process of validation on new requirements suggested. Only add to the scope those changes that prove to add significant business value at an adequate cost. Do not get yourself and your team dragged into an ever bleeding leak of scope that can easily be detected by modern project management tools.

Final Conclusion

As we start we end: simplicity is the name of the game! If you have not yet read that book, please do. The book is named "Insanely Simple: The Obsession That Drives Apple's Success" by Ken Segall.