App Owner and Tech Debt: Detecting and Managing the Unseen

At last, you've found it - an article for understanding technical debt in software development with no tech background, focused on app owners needs, free of tech jargon and needless tech details!

It finally explains in human language just what you need to know for decision-making.

With over two decades in the IT industry, I am convinced that when a project is handled by experts, product owners don't need to know anything about the technical debt - that's the team's domain.

So, if you are aware of this concept, it's a sign that your team has failed, and the problems are already in full bloom. Probably, they are like that:

• The app keeps crashing - users see an error message instead of the intended page.
• The app is incredibly sluggish - no user would tolerate a 10-second site load time.
• Adding a new feature is a daunting task, with deadlines constantly delayed or the app crashes like a toy.

The product owner, confronted with such a disaster, seeks out other developers, only to discover that they must shell up a round sum to reduce technical debt in the app.

What is this all about? How do I know it's really there? Where does it come from? Could it have been avoided? Now what? How to fix technical debt in my app?

Let's start looking at these questions.

What Is Technical Debt in Simple Words?

This is a code written in a rush - full of shortcuts that, while invisible for a while, will come back to bite. It was borrowing time from the future, and now it's time to pay back with interest.

What Is the Source of Technical Debt?

Does technical debt always stem from developer incompetence or malice? - Not really.

Every app's got some technical debt - it's a given in app development. The key is managing it. Therefore, in practical terms, there are essentially two types of technical debt: one that remains under control and another that has spiraled out of control.

Let's first take a look at how it works in a successful project, using specific technical debt examples from real life as we go.

When the Tech Debt Is Under Control

Consider this: we're making a content management system (CMS). This is a tool that lets the client's non-techies post and edit content on their site.

The most common technical debt is code duplication. Here's how it emerges as an app evolves.

Step 1. Suppose the client needs to publish articles three times a week. We design a special form that allows content managers to independently add new articles by filling out fields such as title, author, publication date, text sections, images, etc.

Step 2. The site needs other pages too, like an About Us Page. It's a standalone page that won't be updated often. Do we need to make a specific form for it now? - Not really. We can just add this page ourselves, manually.

Step 3. In a couple of weeks, it's evident that our form lacks a field for the latest article update date. - Articles are updated periodically, that wasn't initially considered. The client wants to fix this flaw in the article publication form and also add the last update date on the About Us page, ensuring readers see that the information is up-to-date.

Step 4. Adding this new feature to both article pages and the About Us Page with the same code is a real head-scratcher because of their major differences. Is it worth the time spent? - Not really. The About Us Page is unique and it's easier to just add a separate line of code to it.

Now, we've got a tiny bit of code duplication, almost identical in two places.

Step 5. The client's trying out new content - event reports - to see what readers think. We've got a new junior developer on board, so they're the one to manually add the first report to the site. - There is no need to make special forms for such pages, 'cause the client might still decide to skip this type of content.

Step 6. The new dev was supposed to add a Last Update Date field when creating the first event report page, but we didn't inform them. This wasn't documented either as we didn't expect team growth. For the same reason, we didn't write a test for a newbie to check the new page for all fields before publishing.

Step 7. We spotted this page defect only after readers caught sight of it - ouch, first bug. That's how duplicate code causes a mess.

If the same code isn't used everywhere but instead manually copied, it's easy to forget to include it next time, especially in a big team where docs are missing and tests are skipped.

Step 8. The client decides to swap the date format of the last publication, so it now appears on the site pages instead of the original publication date.

Step 9. We see - this needs triple effort: making changes in three code duplicates - the article creation form, the About Us Page, and the Event Report Pages. The Rule of Three goes into action. - Time to take the tech debt under control.

The answer to the question of how to measure technical debt is simple: it's based on the number of problems it creates, in line with a specific rule that developers typically adhere to - the Rule of Three for technical debt management:

The client first wants to get the features fast to test them and figure out if they're really needed. It's pointless to build them "to last forever", and optimization is only done after the "third hit."

• The first hit - creating the first duplicate code. It's OK, if we would need to slow down development too much to avoid this. We just document it for later.
• The second hit - code duplication led to the first problem. We're assessing the difficulty of removing duplicates. If it's too costly, we're planning for future optimization.
• The third hit - code duplication led to the second problem. It means we can't delay optimization anymore, 'cause it'll end up costing too much.

This is a common practice that experienced teams employ to keep technical debt low.

Step 10. We're giving ourselves a bit more time to make the changes the client asked for and clean up duplicate code to make future adjustments in one place only.

This results in the most cost-effective development. We only spent on optimization when it was going to cost more than if we hadn't done it.

When Technical Debt Gets Out of Hand

Who is responsible for technical debt piling up out of control? - It's always the development team. There are two main reasons for this:

1. Developers are incompetent and can't handle tech debt, or even don't realize it's a problem.
2. Developers are promising work that's faster and cheaper than it can be, by building up tech debt. - They're duplicating code, and they're skipping over docs and automated tests.

Let's trace the progression of events in this instance, stage by stage.

Stage 1. The development is moving at top speed. The tech debt is mounting, but it's not showing up in the app.

• The client is blissfully unaware, and they're probably happy with the team.

Stage 2. The first sign of tech debt is that it's taking more and more time to add new features. We had just 3 code duplicates in our CMS example, but with thousands of pages on a site, how much time would it take to change each one manually?

• The experienced client will notice a problem and have the source code audited by independent experts. The novice might not realize anything.

Stage 3. Bugs pile up, leading to technical problems - and we clearly see the impact of technical debt in this escalation. The app slows down and critical errors start appearing. The team is entirely focused on keeping the app running, constantly dealing with fires that keep breaking out. This leaves no room for new features.

• The client is probably shifting teams and may first come across the idea of "technical debt."

Stage 4. If the client didn't switch teams, the app's in the final stages of becoming a disaster. It's hard to find a developer who fully understands how the app's parts work. Team's scared to touch it. It's unstable, doesn't meet any standards, and it's dangerous for user data.

• The client could lose the app and the entire user base at any moment.

How to Check Tech Debt in Your App?

It could be done by conducting an independent audit of the app's source code.

These signs are usually found:

• Code duplications and other types of flawed code.
• No documentation.
• No automated tests.

How to Deal With Technical Debt That Got Out of Hand

Most likely, you need to change devs team first of all. Then, we have to pay off the tech debt by investing extra resources to eliminate code duplicates and other accumulated issues. This process is called code refactoring.

Code refactoring means technical debt reduction by making adjustments to existing code that:

• Doesn't change the app's functionality - it continues to function exactly as it did before.
• Often boosts app speed and user data security; however, these benefits of reducing technical debt are bonus points and not guaranteed.
• Conducted with the main goal of eliminating obstacles for adding new features. This is how technical debt vs maintenance differs - the former being about removing hurdles, unlike regular app support.

Experienced developers always focus on reducing technical debt in small doses, doing client tasks in parallel.

For instance, when the priority is to fix bugs or increase speed, developers will refactor the relevant code. On the other hand, if the client aims to enhance functionality, developers will tackle any barriers in the way.

Hence, the product owner will start to see desired changes in the app - at first slowly, getting faster as technical debt reduces.

Sum-up for Quick Reference

What Is Technical Debt Definition in Simple Words?

Technical debt refers to code defects arising from rushed work, which can pile up rapidly in the app unless they're deliberately focused on and dealt with.

Why Is Technical Debt Considered Bad?

It results in problems that grow exponentially, sooner or later halting further development and making the app unusable. The risk of technical debt is magnified by its capacity to build up to dangerous levels without any outward signs.

Is Tech Debt Avoidable?

No, in any app, tech debt is a given. Its root cause is the fact that a feature needs to be tested by users to stick around in the app. And optimizing it beforehand is a waste of resources.

What Are Types of Tech Debt From the Perspective of an App Owner?

App owners don't need to get bogged down in the different technical debt categories. The critical point to grasp is whether it's a controlled and manageable type or one that has spiraled out of hand.

How Do You Control Technical Debt in Regular Development?

Experienced developers do it in this way:

• Keep the tech debt in check, preventing it from escalating into excessive costs.
• Reduce tech debt in small bits, only a bit slowing down the delivery of new features.

What Are the Causes of Technical Debt Harmful Accumulation?

The root causes of harmful technical debt buildup are found in the development team, either due to a lack of skill or awareness in handling tech debt, or their approach to deliver work quickly and cheaply at the cost of accumulating suboptimal code.

How Do You Identify Technical Debt, as a Product Owner?

The first sign of tech debt in your app is that adding new features takes more and more time. Precisely this sign allows for spotting early tech debt in your app. If you've noticed this, it's best to conduct an independent audit of the app's source code right away.

What Can Poor Technical Debt Management Lead to?

Neglecting technical debt ultimately causes critical troubles, including frequent app crashes, painfully slow app performance, and an exceptionally tough process for adding new features.

How to Prioritize Tech Debt Remediation With a New Team?

Experienced developers balance tech debt with new features by tackling technical debt in small doses, focusing on those parts of the code that are directly needed for fulfilling the current client's request.

Therefore, the product owner notices:

• Gradual implementation of their requested features in the app, initially slow but then increasingly swift.
• Consistent enhancement in the overall operation of the app - it's faster and suffers fewer failures.

How to Avoid Technical Debt Issues Simply?

The best way is to hire developers who stick to industry standards.

Development cost-cutting, if it's achieved by piling up technical debt, is a phantom economy that may come with extra costs in the future - they'll escalate geometrically.

Your project's a mess? We've got the skills - get in touch, and we'll show you how to straighten it up!