Bad Performance.
A term familiar in the worlds of business, finance, education, entertainment and sports, and also not a pleasant one to hear. With the growing maturation and saturation of the use of mobile apps, avoiding bad performance is crucial if you want your app to succeed. Avoiding technical debt is a big part of that. Bad performance should never be taken lightly.
On several occasions, I’ve met with potential clients who need to address bad mobile app performance issues that seemingly came out of nowhere. These issues manifested in the form of crashes, bugs, latency, outages and bad UX flows, and led to dramatic increases in user attrition. In short, these apps and businesses found themselves in a potential death spiral with a bleak future ahead of them.
Comprehensive code and performance audits would uncover a myriad of causes:
- unstable code architecture (caused by quick and dirty coding practices)
- outdated API services and endpoints
- archaic 3rd party services
- the continuous addition of features that ignored platform and UX standards
- hidden code dependencies
These causes did not appear overnight and many companies that released mobile apps anywhere from 2-4 years ago now find their products performing poorly. Why? Technical debt. And like financial debt that isn’t paid off and only continues to grow, technical debt can have dire consequences if ignored.
Related: Why Your Brand Needs to Invest in a Mobile Strategy Right Now
What is technical debt?
A common definition of technical debt is “the accumulation of errors in architecture, design and poorly written code.” However, it’s important to know that often technical debt is the result of impractical, ill-advised business imperatives or product decisions that complicate the initial and ongoing design and development of applications. Like so many common human health problems, technical debt can be remedied if treated early or in the case of software, addressed through regular refactoring with close attention paid to architecture and scalability.
Source: Pexels
However, if left untreated, technical debt can mutate to become an app’s cause of death more quickly than most businesses realize. In fact, the cost of maintaining an application can seriously increase if product owners or brands avoid addressing technical debt, eventually making it almost impossible to add new code and features. Let me provide some fatal technical debt scenarios aggregated by Hacker News and a few other sources that might sound familiar:
- The case of misguided solutions: A travel company rushed to get their app to market, haphazardly building on top of outdated and new API frameworks and vendor integrations, while also adding new features with a lack of consideration for UX and backend dependencies. Code architecture and API performance became incredibly unstable over time resulting in system instability, poor performance and increasing user attrition each quarter. When early signs of tech debt began to show, the first failed solution was to triple the number of developers on the project without addressing the tech debt. This actually sped up the app’s death spiral and compounded technical debt.
- The case of mysterious and unsolvable breakage: The product simply stops working and the team is unable to get it working again. This can happen with really ancient legacy products where the original team is gone or young products are written badly by inadequate teams.
- The case of unpleasantness: A product so difficult and slow to work on that the company simply loses interest and shuts it down rather than suffering through more maintenance.
- The case of outsourced code: The tech debt was never as bad as you described, but it was a small company operating on a short runway. This taught me an unfortunate lesson about non-technical founders and the dangers of outsourced code.
- The case of quick and dirty development: Tech debt is accrued when software is developed the “quick and dirty” way in an effort to meet a strict deadline. In our case, our developers were taking shortcuts and writing code that wasn’t quite up to TSheets standards – if only to appease the customer and get the feature out the door. Unfortunately, this type of tech debt adds up fast – and it ends up costing even more time and money in the long run. (Don’t worry, we learned our lesson.)
The scenarios above are from those who have worked on projects threatened by technical debt. Let’s also look at how symptoms of technical debt and bad performance impact users. First, it’s important to understand the common user’s perspective.
According to The App Attention Span, a study conducted by AppDynamics and the Institute of Management Studies (IMS) at Goldsmiths University of London, user expectations and standards continue to rise while common performance problems persist, causing repeated frustration and stress that leads the user to more quickly decide to stop using an app. In fact, “more than 8-in-10 in the U.S. (86 percent) and 82 percent in the U.K. have deleted or uninstalled at least one mobile app because of performance issues.”
Source: Derek Anies
In addition, the potential for the loss of business doesn’t stop there as mobile users are likely to vocalize their dissatisfaction and openly discourage the use of a badly performing app to family and friends, while also taking more initiative to write bad reviews in the app stores. However, users also reward businesses that provide well-designed and well-performing mobile products, as “1-in-3 study participants stated that they would spend more money with an organization if they had a good mobile app.” Do any of these causes and symptoms of technical debt and bad performance sound familiar?
- Is your engineering team struggling to implement new features in a timely manner?
- Are they missing deadlines because they’re spending most of their time on defects and bugs?
- Are you seeing a growing number of crashes, outages and latency issues?
- Are you experiencing an increase in user attrition and a decrease in app-related revenue?
- Have your app store ratings gone down in the last 2-3 quarters?
If you answered yes to any of these questions, it’s time to consider a treatment plan and stable|kernel can help. We’ll start with a comprehensive systems review, application audit (of design and code) and process review. We will begin the app audit process by verifying that we can build and run the app and also run automated test suites. For an Android app, we will attempt to run the app on multiple devices in order to test its performance across a representative sample of the Android versions intended to be supported.
From there, we will delve into the codebase to identify issues and provide recommendations to address them. The review of the codebase includes an extensive investigation into and testing of: third-party components and license compliance; code quality and maintainability; automated testing; web API complexity; memory usage, data storage and performance; security; and UI, including accessibility, internationalization and localization (if applicable). With this information, we’ll be able to diagnose the root causes of your application’s technical debt and present several options for pulling your app out of the technical debt spiral. Solutions could include an intense refactoring phase or possibly designing an app architecture that adheres to the highest coding and platform standards, saving you time and money in scalability for the years to come.
