Comprehensive Software Reviews to make better IT decisions
Drowning in Tech Debt? The Pandemic Is Your Opportunity to Pay It Down
We live in a consumer society, always wanting more and willing to incur debt to get it. In a hyper-competitive for-profit economic system, product and service providers notice this behavior and want to capitalize on it. In fact, one could argue that this human bias towards variety has pushed software-supported products and services to impose unreasonable expectations on their tech teams to deliver more and deliver faster. Teams have responded admirably by upping their speed but with an unintended consequence: the increasing scourge of technical debt.
Info-Tech works with many members from diverse industries. These members range from small private businesses with a skeleton IT staff to large organizations that can only provide their services on the back of a reliable and performant technology infrastructure.
Irrespective of their size …
… most members inquire about the best way they can provide value to their customers through better requirements management practices, designing better applications, using DevOps and automation, and reliability engineering. Surprisingly (or in fact, not), again irrespective of their size, most members are also wary of their technical debt burden. They know they’ve incurred it and must think about “paying it down” but don’t have the time to do it effectively.
Technical debt is such old news – may we change the channel please?
Touch that remote only if you can confidently say you have never pushed a hot fix or a critical new feature to production while bypassing the fundamental rules for good system design.
Technical debt is like a virus. It may or may not show its effect right away, but it’s hidden deep inside the crevices of bit and bytes, waiting patiently for an opportunity to turn into a chronic ailment. When it does make the leap, you can expect it to rear its head perpetually till the patient undergoes an invasive surgical procedure to cure itself.
You can’t compare technical debt to a virus. This reminds me of Fake News!
Not at all. In fact, a recent report by Accenture showed approximately 70% of executives surveyed acknowledged technical debt was a hinderance to innovation, an obstacle for migrating to new platforms, and a factor seriously curtailing their ability to react to market changes.
Technical debt, as a result of bad software engineering styles, accumulates over time. Tech teams make one small design compromise (with the honest intention of fixing it later) to meet the business deadline, but eventually, making compromises becomes the default. Suddenly, good design practices become an afterthought because as one member very eloquently explained, “some days, I just want to push the code to production, go home, and not be the reason the business feels IT betrayed them.”
Increasing technical debt is a self-fulfilling prophecy on an infinite loop. Tech teams are okay with increasing the debt in the interest of time, but the side effects of such actions result in system failures that are fixed with shoddier band-aids. Ultimately, the amount of time that tech teams end up spending on fixing technical debt issues consumes most of their working hours.
Consider paying down your debt while you wait for the current pandemic to subside.
Governments in most major metropolitan areas have called for shutting down non-essential services, effectively rendering those who work in such services either jobless or unproductive. Software engineering teams that support these non-essential services are for all intents also non-essential.
Unexpectedly, tech teams have time on their hands as they shift their focus to keeping the lights on.
Follow our structured approach for getting a grip on the scope of your technical debt challenge.
Fail to plan and you plan to fail. Identifying where technical debt is hidden and how to prioritize its removal from different systems and then actually doing it is non-trivial. A brute-force clean-up effort will only increase the target system’s vulnerability and may even damage the system.
Info-Tech analysts have helped many members successfully reduce their technical debt and in general suggest the following phased approach:
Phase 1: Find out what really bothers you.
- Understand challenges with technical-debt-laden products.
- Prioritize your applications portfolio.
- Create a list of applications (in sequence) that need remedial action.
Phase 2: Clean up technical debt.
- Prep for refactoring.
- Actually refactor.
Phase 3: Sustain the benefits for the long term.
- Automate development.
- Implement automation testing for all environments.
- Automate deployment for all environments.
Chickens have a habit: they always come home to roost. Likewise, the consequences of quick fixes and compromises can come back to haunt tech teams. For instance, remote working in our current times has exposed some chinks in our technology. Using trusted collaboration tools like WebEx, Microsoft Teams, and Zoom has not been painless. This analyst suspects the creators of these tools are probably sheepishly thinking about that “one little piece of ad hoc fix” that opened their debt account (one they never could pay off, and now they are drowning in debt).
The need for speed in product delivery has created the ideal breeding grounds for bad software engineering attitudes. Inevitably, technical debt builds up and starts becoming an obstacle to moving forward. Ad hoc remedies and Hail Mary passes for mitigating the side effects of technical debt can only work for a limited time. Responsible software engineering teams will always account for building resilient and performant systems as part of their delivery promises. It’s just common sense, after all, that the best way to get rid of any debt is to actively pay down the principal. Your systems' credit score and ability to get a “loan” depends upon it.
Want to know more?
Modernize Your SDLC: Strategically adopt today’s software development lifecycle good practices to streamline value delivery.
RPA projects fail more often than one would expect. The ease with which RPA tools allow workflows to get designed and implemented makes it easy to avoid building a strong foundation for the work being done.
We live in a metrics-fixated world where having more metrics is always thought to be better than having less, and Software Development Life Cycle (SDLC) metrics are no exception. But the truth is that any badly chosen or managed metric will do more harm than good to your organization. To avoid these pitfalls, take ownership for SDLC metrics away from managers and put it into the hands of those who can best manage it: your development teams.
Robotic process automation (RPA) success is dependent on the right business processes to automate. Blueprint helps identify the right places to apply RPA with its Enterprise Automation Suite.
Appian, a prominent low-code development vendor, announced the acquisition of Novayre Solutions SL, developer of the Jidoka RPA platform. This acquisition bolsters its image as a viable vendor to empower the business with development capabilities.
A prevalent urban legend in enterprise tech is that DevOps and Agile are not ready for tackling transformation at scale. At Info-Tech Research Group, we believe it’s the other way around. DevOps practices like CI/CD are being used by digital banking startups for fintech products. They are leveraging cloud services for demand management and capacity planning but what about the “too big to fail” banks, with global outreach and massive investments in legacy tech?
Agile Tips the Balance Toward Success for Most Projects (but It Takes Time and Effort to Become Agile)
In 1994 the Standish Group published its first CHAOS Report, which famously reported that only about 16% of software projects were completed on time and on budget. Over the years, this staggeringly low success rate has thankfully more than doubled (albeit with a modified definition of success).
Although pair programming is not a widely employed technique, there are reasons for using it, even if you aren’t using extreme programming.
There is a difference between something’s form and its true function. To really understand if a tool is useful for you, study its function, because the form can always change (and in some cases, become misleading). Agile is not immune to such corruption.
DevOps took the industry by storm, and successful organizations see improvements in software delivery processes and product quality. However, speed and quality are not everything. The question is whether the latest products deliver business value. Enter BizDevOps.