🐘Let us talk about the elephant in the room : Technical Debt.
👷♂️ Software Architect Series — Part 3.
Every IT organization (okay! Almost every IT organization), has to address Technical Debt at some point of a product development cycle. It is just matter of time before it creeps in. So, let us understand what leads to Technical Debt.
The term “technical debt” was first coined by Ward Cunningham, to describe how decisions made in a product lifecycle lead to problems which get increasingly difficult to solve over time. And with time, it gets more difficult to fix the issues, constantly incurring interest (cost to fix).
Now, there are some factors which are common across IT organizations, which lead to technical debt. And among them, the most prominent being the competing goals of Development and IT operations. While Development takes on responsibility to address new feature requirements as per changing market needs, and implementing and deploying the changes to production as quickly as possible, Operations hold the fort to make sure the services being provided to the customers are stable, reliable and secure. Naturally, Operations will make it difficult for new changes to be introduced as they have the capacity to cause production failure, when compared to an already working version in service.
⚔In short, Development and Operations have goals aligned diametrically opposite and it puts workers into situations of conflict that lead to poor software and service quality and bad customer outcomes.
In IT operations, documentation of the existing application and infrastructure is very critical as they are complex and fragile. If a proper documentations is avoided or not maintained and delegated as future work, it keeps getting delayed and at some point even if taken up, it fails to capture all intricate details, as memory of them fade away with time and there are multiple new entities at play in the system, making it more complex.
Another reason for every surmounting technical debt is the false promises made by stakeholders and agreeing to unrealistic timelines to please customers, in the greed of revenue. This creates a situation of urgency, which often results in corner cutting while implementing solutions and promise that these will be addressed in future (which is inevitably bound to fail!).
👉And slowly, before we realize it, we are already trespassing the jungles of Technical Debt, with day to day work requiring more communication, approvals, and dependency. Work timings start getting longer and production code deployments are taking ever longer to complete, moving from minutes to hours to days to weeks. But worse of it all, the deployment results start causing problems at customers end with frequent outages and mission critical bugs to resolve core functionality. And as the ship sinks, day by day, it causes frustration and conflict in all domains possible. As they say it, when IT fails, entire organization fails.
📕 Meanwhile, if you are a young developer and interesting in building thought process to develop enterprise application, do check out my book: “Objects, Data & AI”, which has been out recently. Book can be accessed at the link below:
https://objects-data-ai.github.io/
This book is available at Google Books as well and print copy can be ordered from Notion Press.
Contact me, for specific details.