Supporting Workplaces of the Future — How Technical Debt and “Bad Code” is Slowing Down Modernization (Part 2)
In our last article on technical debt, we looked at the infrastructure impacts of systems which have evolved inorganically over time. From additional capex to opportunity costs, from attrition to a measurable productivity dip, debt has far-reaching implications for organizations trying to go digital. Read the full story here.
Let’s now focus on “behind the scenes” efforts to understand how application developers contribute to — and can prevent — technical debt.
Decoding the Drivers behind Debt Incurrence
Although it may seem counterproductive, developers and product design teams often add to technical debt and unknowingly pass it on to their customers. This can be due to one of three reasons:
● In a bid to reduce time-to-market (TTM) this would be true for external facing apps and as well for internal facing more, developers may skip code remediation steps that aren’t absolutely necessary to the feature at hand. This may help them get a product to market faster or complete a sprint on time, but continues to pile on “bad code,” in addition to new features and upgrades across the software development lifecycle. Internal applications continue to suffer from lack of optimization and alignment to organizational strategy & structure.
● In case the product design contains inherent flaws, these will only become more prominent after a period. Workplace application providers are always looking to balance simplicity with future-readiness i.e. focus & prioritize actions on UX. However, there may come a time where the original design requires a complete rethink to function in the present context. Outdated design is a technical debt pitfall that is probably the hardest to avoid.
● Multiple incremental changes, large-sized developer teams, the lack of good leadership, and inadequate knowledge transfers lead to complex code. Team members may not understand the foundational concepts behind the product, inadvertently incurring debt while trying to be efficient. There can also be a functionality leftover from the past code, but overlooked in consequent releases. As a result, it gets redeveloped as a new feature! Unaware of duplicate functionalities, the navigation route used to reach the feature becomes extremely confused.
Now, as workplaces begin to go digital, the impacts and reverberations of technical debt are bound to resonate across organizations. This holds true, especially in the context of Software-as-a-Service (SaaS) based digital applications. SaaS products witness continuous upgrades, geared to keep workplaces ahead of the modernization curve — in theory, vendors are to provide the best features, address popular change requests, and remove bugs on the path to continuous improvement. The challenge for these companies to get the customers to be aware of new release, consumption of the new feature and
The reality, however, is often different. A 2018 report estimated that an average developer spends 3.8 hours a week on bad code! Elements that are overlooked (or deemed low priority) are retained in the product and passed down to customers. While this may drive application growth in the short term, the model’s long-term sustainability is limited.
“
An average developer spends 3.8 hours a week on bad code.
”
Consider how in 1996, Netscape Navigator was a search engine giant with an 80% market share. But between ’96 and 2002, Netscape’s software development lifecycle fell on the wrong side of the speed versus quality debate. Each new function only made the code worse, until the insurmountable technical debt brought the project to a halt.
A similar instance occurred at Trulia, another search engine — but in the real estate domain. “The tech industry has made rapid advancements in just the past decade. As a result, companies have accumulated tremendous technical debt. At Trulia, for example, we accumulated 13 years of tech debt — a byproduct of our rapid growth,” said Deep Varma, VP of Engineering at Trulia.
“
We accumulated 13 years of tech debt — a byproduct of our rapid growth.
”
Analyze Your Debt for Effective System Remediation
At its core, debt depends on the fragmented nature of IT. Multiple IT functions could be at different levels of alignment to business objectives. The first step on any debt remediation journey involves taking stock of this as-is scenario.
· Age of the IT estate: Legacy estate, agile estate, SaaS estate, or combination of these might be driving IT. In other words, age isn’t a measure of product deployment timeline. When calculating the age of your IT estate, look at factors such as lifecycle support, documentation maturity, and ease of knowledge transfer.
· Maturity of the IT estate: Maturity refers to performance capabilities of IT on a day-on-day basis, powered by industry support. Beyond simply features and business alignment, you should check for cyber vulnerabilities, market support for the underlying stack, ease of 3rd-party/home-grown integration, and frequency of unexpected operational failures or breakdowns.
· Design of the IT estate: IT components such as infra architecture, app architecture, business architecture, or data architecture isn’t normalized while they serve the purpose. This is the “don’t fix it if it isn’t broken” approach. But when transforming the business — scaling, improving performance, changing UX, etc. — these disparate design elements come into conflict. For example, your network was originally meant to handle data moving only through internal systems. Once you begin expansion, opening up to integration, your networks are pushed to handle significant amounts of data moving both internally and externally. Debt like this will stop you from moving to the cloud.
That’s why it is important to proactively build change management programs which will consider remediation demands, besides addressing new functionalities/upgrades. In addition to just code remediation, this is a more holistic approach.
But let’s begin at the beginning. A majority of debt can be addressed at the code level — all it requires is strategic contributions from developers.
Best Practices for Debt Prevention
In many ways, technical debt is an indicator of code quality. If developers are spending more time on past code remediation, than new innovations, the product will always be one step behind. In fact, the same report cited above mentioned that developers spend nearly a third of their workweek on addressing debt — this is clearly too much.
As we move towards rapid digitalization of the workplace and dependence on software tools (for communication, payroll, project management, document management, customer relationships, you-name-it) the debt problem will only increase in severity. That’s why developers must:
● Balance agile methodologies with consistent backlog clearance
● Boldly face refactoring system requirements, and not shy away from a redesign
● Strengthen knowledge transfer mechanisms so that a single product vision is perpetuated across teams and developers
● And finally keep a log of what features are being used i.e. develop a demand and consumption matrix so that when you refactor or address backlog, so that prioritization becomes easy.
Just as financial debt deters economic growth & development, technical debt could become a massive roadblock on our modernization journey, if not nipped in the bud. Beyond these four foundational steps, emerging technologies like cognitive science and Artificial Intelligence can help redefine software development, bringing in exceptional levels of accuracy. Needless to say, AI will eliminate the human factors which lead to debt, and organizations who find themselves riddled with debt, should consider a holistic system-wide approach instead.
In our next blog, we consider how cognitive could be the “magic bullet” for successful workplace modernization. This was discussed briefly in the last chapter — watch this space for the full story, out soon.
