Managing Frontend Tech Debt

Niya Panamdanam

Twitter: @findniya

Website: findniya.com 

A little about me...

Managing Frontend Tech Debt

We all deal with it.

Article: https://www.reforge.com/blog/managing-tech-debt

What we are going to talk about...

Understand that Tech Debt is not bad.

1

Common Assumtions

Tech Debt is an umbrella term and can mean a lot of things.

2

Types of Tech Debt

Prioritizing Tech Debts as part of a strategy for improving the product.

3

Strategies for
Tech Debt

Common Assumptions

Tech Debt is

  • Bad.
  • Complicated.
  • Not Product Work.
  • Developer pain and is the same as Organizational pain.

Tech Debt is
NOT BAD

  • Break the bad reputation Tech Debt has, and appreciate the progress.

It is mark of progress.

  • Not all Tech Debt is equal. Break them into categories and smaller tasks.
  • Some Tech Debt is good and is acceptable.

Tech Debt is not ALL Complicated

Defined

There is a start and end to it.

Ex: Adding documentation for front-end components.

 

Undefined

There is a start but it's hard to predict when it will end.

Ex: Major library updates.

Defined vs Undefined

Tech Debt Work is Product Work

  • Empathy is key.

Tie To Metrics

  • Communicate the user and product benefits.
  • Talk to the business side and tech side. Make sure everyone understands why it is important.

Developer Pain is not Organizational Pain

Questions to ask if this Tech Debt is affecting just you or the organization.

 

  • What is the impact on users or the business

  • Do others in different teams also feel the same pain?

  • Is there a reason why things are the way they are?

  • Does your leadership understand the value of fixing this Tech Debt? Will they support you?

Empathy

  • Maintenance
  • Developer Efficiency
  • Stability
  • Security
  • Technical Product
  • Decision

Types of Tech Debt

Not keeping up to date.

 

Some examples:

  • Cleaning up dead code.
  • Library updates.
  • Updating documentation.

Maintenance Debt

Engineering workflows are bogged down. Not having tests or alerts for issues.

 

Some examples:

  • No real feature tests or no confidence in the tests.
  • Developers can't do experiments to verify.

Developer Efficiency Debt

New features or work on certain areas, affect the stability of the infrastructure or the core product.

 

Some examples:

  • Areas of the code base that you are terrified of making a change.
  • The team is constantly reacting to production bugs/ crashes.

Stability Debt

There is immediate and visible user impact.

 

Some examples:

  • Performance issues.
  • Potentially caused by other types of Tech Debt, but users can see it.

Technical Product Debt

Past technical decisions with some tradeoffs and the team is paying for it now.

 

Some examples:

  • HOCs vs Hooks.
  • Using REST APIs vs GraphQL.

Decision Debt

  1. Quantify the size of the Tech Debt.

  2. Prioritize when to work on Tech Debt.

Stratergies for Tech Debt

  • Pretty small changes.
  • Can be done in a day or so.

 

Ex: Going back after the sprint to write documentation.

Acute

Systemic

  • Huge undertaking.
  • Will take more than a few days to months to fix it.

Ex: Moving to start using Typescript.

Size Tech Debt

Ways to Prioritize Tech Debt

1

What is the likelihood that this will lead to larger problems?

CONFIDENCE

3

USER IMPACT

How does it affect user experience?

5

ACCUMULATED DEBT

How much debt do you already have?

2

When will this become a problem?

TIME

4

Does this block important milestones?

SEQUENCE

The only problem we really have is we think we're not supposed to have problems! Problems call us to higher level – face & solve them now!

– Tonny Robbins

Q&A