Technical Debt: What It Is and How It Impacts Your App

Technical debt is an interesting concept that’s been making its way into mainstream headlines over the last couple of years because it’s become a pervasive issue across the entire app ecosystem. More and more, organizations are openly discussing their relationship with the often expensive problems this creates for their business. This begs the question: what’s the common denominator?

Depending on the business, technical debt can range in severity from being a small blemish in your IT and software development expenditures to a crippling “tax” you seemingly can’t escape. In any case, it’s something you should try to minimize whenever possible. To do this, it’s important to understand how it affects business so here, we’re going to explain what technical debt is and what causes it, then explain how it can impact your ability to deliver timely, much-needed updates to your app or digital product.

What is technical debt and what causes it?

Quite simply, technical debt most commonly refers to additional costs that are incurred to refactor a digital product, such as a mobile app, because of limitations imposed by expediting the development process (in part or whole) to meet a deadline. In plain English, it’s extra money you need to spend because something was half-assed to save time.

Of course, there are other decisions that can lead to technical debt as well. Sometimes, a certain technology is selected that’s considered the “best” for its time but it loses relevance over time or is eventually outclassed by something new. An example of this is the Windows Communication Framework (WCF), which in the mid-aughts was Microsoft’s premier framework for building distributed applications. However, since then it has been long outclassed by newer, simpler frameworks such as ASP.NET Web API and many others. As WCF has faded into memory, so too has the skill sets needed to modify and maintain codebases built on them. 

So why does this happen and why is it so common? Consider the following:

Our world is built around convenience – virtually every solution we have for anything you can think of usually makes whatever it is easier. You don’t have to load up a cart and yolk up your horses to go to Aunt Ruth’s house so she can teach her how to whip up her legendary bread from scratch, you can bake together from your own homes over FaceTime. While not every modern convenience outshines its old-fashioned counterpart in every way, it certainly sells. And herein lies a little problem.

A horse is an infinitely more fuel-efficient option than a Volkswagen or BMW as well as boasts far fewer electrical problems but if you look around, you’ll notice very few horses on the roadways. Emerging and existing leaders in a marketspace – à la the German vehicle manufacturers above – take notice and go full bore into delivering what they understand to be valuable in the eyes of their audience. Though it is crucial to get to the market quickly, like when delivering an MVP, there’s a right way to shave off time and usually an even more appealing method that’s even faster. The problem with choosing the latter is this usually sets the stage for an ongoing, problematic experience for your customers.

The paradox here is that the market demands speed which makes shortcuts attractive but the reality is that the costs can end up eating the value that being first or early offers. With that said, sometimes knowingly taking on technical debt can be likened to capitalizing on certain investments – sometimes, you’ll need to borrow in the interim to get by or just to get over some hump.

Though you can’t see into the future to know for sure when some technology’s usefulness will begin to wane, you can avoid decisions that typically lead to technical debt issues. One of the main ways this can impact users is your ability to appropriately update your app which we’ll discuss next.

How technical debt can affect the ability to properly update your app

As we touched on earlier, there are times businesses will experience technical debt to no real fault of their own. For example, over the years many programming languages that were once best-in-class solutions (or, the only thing available) have become obsolete simply because of a variety of changes in hardware and software that render their very foundation to be mostly ineffective. C

Currently, we see a lot of technical debt in the form of maintaining hybrid app frameworks which were all the vogue a few years back. With the advent of true cross-platform frameworks like React Native that do not come with the same baggage as hybrid apps, many developers have abandoned these hybrid frameworks leaving libraries unpatched and issues festering that have been introduced by new versions of iOS. Thus, fixing and maintaining codebases built on these hybrid frameworks is becoming more expensive and time-consuming.

It’s like how the typewriter quickly gained popularity because it outclassed the pen in terms of speed – the electric typewriter would improve upon the design of the original and fast forward to today, most of the communications we send are digital and our “typewriters” are just pieces of software.

Something better and substantially evolved will eventually come along but in the meantime, it’s important to find solutions and make decisions that are centered on scalability for today’s needs and the foreseeable future. The main idea is that you need to be able to: update your app around each mobile app store’s guidelines or run the risk of being booted, fix bugs and make performance improvements to keep users happy and add new features to increase your overall value.

A few of the most common issues that can lead to technical debt are as follows.

Make the %&^# thing work, NOW!

There are times that, for whatever reason, a fix, update, or new feature addition encounters an issue that puts teams at a kind of impasse. Certain workarounds – such as reverting to an “old way” of doing something or using a hacky, hard-coded patch to get something out the door – will eventually need to be refactored. Plus, software can act up, even for developers, and further, venturing into new territories will uncover “unknown, unknowns” which can slow teams down and increase costs.

Speed limits and traffic laws aside, you can only take corners so fast before your vehicle just kind of slides into oblivion. Sure, getting to the market quickly is important but doing it “right” is often more cost-effective than “right now.”

You just need “something” on the market

Yes, yes you do. What you need is an MVP that’s been methodically planned and tested as well as an underlying intention to develop iteratively based on feedback and data.

Getting an MVP doesn’t even mean releasing a highly polished product as the idea is to release something that engages its target audience enough for you to test the product in the real world and gather feedback. Everything needs to be built with the future in mind or you need to have deep pockets like Walmart.

Walmart’s first mobile app was a lumbering mess of a hybrid app, which is one style of mobile app we don’t endorse. However, this was common practice a decade ago and it got them on the market at the right time to keep trading blows with other big-box retailers in the mobile app space. But eventually, they scrapped the whole frontend of the app in favor of React Native.

Obviously, Walmart has deep enough pockets that this worked for them. By design, a hybrid app can only be so good so they effectively eliminated all (well, most) technical debt for their app by creating an entirely new frontend. The lesson here is that sometimes the only way to get out of technical debt is to basically “pay it off in full.”

Low-code solutions are a recipe for disaster

We did a hot take on low and no-code solutions last year and the sentiment is still the same. While these solutions aren’t entirely useless – they’re actually ideal for motivated people to build their proof of concepts – they inherently lack the raw customization that true coding can provide. 

Almost every app that relies on such frameworks will typically encounter a couple of issues. Certain systems don’t have the flexibility to allow deep editing that’s necessary for customization and if it does work well with custom code, then it begs the question of why you’re using such a solution in the first place. Over time, these systems become encumbered with code “modules” that either do way more than what’s needed (i.e. they’re inefficient from a code standpoint) or do too little. This can lead to issues with applying needed updates down the road, whether it’s for a new feature or simply some changes to appease one of the mobile app store’s guidelines.

Not using iterative development

The reason we and other agencies stand by iterative development is that it adheres to just about every agile methodology in the sense that it’s flexible. More specifically, it allows one to learn about the product and audience then build around it while minding the product roadmap. By using a combination of custom code and robust third-party APIs, we can create tailored solutions with the elasticity to grow over time.

Developing in large chunks is risky and costly, especially when a change requires a massive overhaul. Doing a little at a time helps ensure features are working well enough before adding another layer. Kind of like when building a new home, it’s a lot more difficult to go back and fix a wiring issue if the project has moved to the “sanding drywall” phase. This also mostly eliminates the possibility of any significant technical debt as everything is scaled to proportion on frameworks designed to support the product for the long run.

We design solutions to grow and scale throughout their lifecycle

The frameworks and architectures we use to build apps are forward-thinking – the solutions we design are able to grow with your business and userbase into the future. We help you understand technical debt as it relates to your business goals, whether we’re helping you build a brand new product or refactoring an existing system. For more information or to talk with us about helping with your project, get in touch.