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
-
Quantify the size of the Tech Debt.
-
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
Managing Frontend Tech Debt
By Niya Panamdanam
