Technical Debt Prioritisation - Identifying And Fixing Highest ROI Issues
Does your technical debt backlog look endless? Are you thinking about pausing feature development to resolve tech-debt? Stop. What if I told you that a good chunk of your backlog can simply wait? Tech-Debt can seem overwhelming when we look at it as a loosely organised list. This can lead to several anti-patterns in how we deal with them. Attend this session where I will be sharing strategies we have been leveraging to identify high priority tech-debt items to make sure we are able to continue feature development while improving code health.
Problem Statement: Tech-Debt often accumulates until productivity takes a serious hit and then as a knee jerk reaction we try to clean it up all at once. At this point there is just one large list of issues with a loose sense of priority. Net net it gives an impression that we have a huge backlog. This can lead to several anti-patterns.
- Chicken and Egg Problem - Too much Tech-Debt, so feature development is slow. Since feature development is slow, we cannot set aside time to fix issues.
- Fixing the wrong issues - In the larger scheme of things, it may be counter-productive to fix low priority issues just because they are easy.
- Pausing Feature Development - Approaches such as "Technical Debt Sprints" where we pause features to resolve tech-debt are not be sustainable even if they offer some short term benefits.
- Local Optima - Patchy cleanups which lead to uneven code health across the code base.
- And many more
Solution: Understand the impact of each Technical Debt at Block, Category and Item level to narrow your backlog to those issues which matter. While there are several tools that help us identify tech-debt it is up to us to map our context on those issues. Attend this talk where I will be going over how to VISUALISE, TRIAGE, PRIORITISE and STRATEGISE in order to get a realistic view on your tech-debt. Also I will be sharing my experience about how we have been leveraging time boxes and capacity constraints as a tool to make sure we are only working on the most important tech-debt issues.
Topics that will be covered:
- Tech-debt resolutions strategies - Anti-Patterns
- Tech Debt - Understanding Size vs Impact
- Tech-Debt Manifestations - Matrix view of areas of code and types of problems.
- Visualise - Triage - Prioritise - Strategise
- Visual techniques to understand your tech-debt backlog with code analysis tools - Examples with popular tools
- Bubble Charts - Coverage vs LOC, Maintainability vs LOC etc.
- Git History - Multiple ways of looking at changes to a piece of code
- Active Code Paths - Mapping usage to issues
- Mapping Project Management Data - Bugs, Stories that touch a piece of code
- Triaging the backlog to quickly eliminate tasks that can wait
- Block level - Leveraging Logical Architecture
- Category vice - Example: Front-End, Backend, API etc.
- Item vice elimination
- Refactor vs Rewrite
- Prioritising tech-debt with layers of detail such as - Churn, LOC, Coverage, Bugs etc. Hotspot Identification.
- Strategise - Approach to resolving each tech debt item based on Tech-Debt Manifestation Matrix
- Visual techniques to understand your tech-debt backlog with code analysis tools - Examples with popular tools
- Tech-Debt resolution - Hypothesis based, Data Driven approach
- A template to capture your hypotheses, experiments and learnings
- Visual confirmation that the issue is resolved
- Just-Enough resolution - The uncomfortably short time-box - Imposing constraints to avoid runaway clean-ups
- Guard rails to avoid a repeat of the same issue
- Incorporating tech-debt resolution into your Iterations, Weeks, Sprints, etc.
- Identifying the right cadence on how often you fix debt - Hours per Day, Days per Week etc.
- Tech-Debt back log Grooming
- Cycling through categories of tech-debt
- Measuring Progress
- Short-term - Measuring immediate impact on the code
- Medium-term - Productivity improvements (Readability, Issue resolution time, etc)
- Long-term - Team Health - Knowledge Silos, New Team Member Onboarding Time
Outline/Structure of the Talk
- IceBreaker Self Evaluation Questions to help Audience relate to the topic - 2 mins
- Understanding tech-debt size vs impact, problems with fixing low priority issues - 8 mins
- Introduction to "Visualise Strategise Prioritise" approach - 10 mins
- Tech-Debt resolution approach - Leveraging intentional small time boxes - 10 mins
- Incorporating tech-debt resolution into your Weeks, Sprints, etc. - 5 mins
- Measuring Progress - 5 min
- Q & A - 5 min
Learning Outcome
- Strategies to visually identify highest yield, lowest hanging tech-debt by analysing multiple sources of data
- Prioritising Tech - Debt at module / block level, category vice and at item level
- Setting up Learning / Governance around tech-debt resolutions to drive accountability and avoid repeat effort
- Avoiding analysis-paralysis that usually comes with "Pause and Fix", "Technical Debt Sprint", etc. with techniques that emphasises consistency over quantity
Target Audience
Tech Leads, Architects, Senior Devs, Engineering Managers, Heads of Engineering, Engineering Leaders, Architecture Consultants
Prerequisites for Attendees
- Experience handling technical debt clean up such as reducing complexity, increasing coverage, improving readability etc.
- Practical knowledge using any of the popular static code analysis tools
- Experience Rewriting Applications will help
Video
schedule Submitted 2 years ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Jason Yip - 8 guiding principles for Agile Coaches (or change agents) from the Spotify Ads R&D Agile Coaching team
20 Mins
Talk
Intermediate
An introduction and explanation of 8 guiding principles design by the Agile Coaching team for Spotify Ads R&D and how they might help you with your own change efforts
- We are more impactful with both team-level insight AND leadership relationships;
- We should not become operational (or at least be careful about becoming operational);
- Focusing too much on short-term tactical wins limits the ability to have sustained impact;
- Coach (aka change agent) collaboration is more effective than silos;
- Results are for the short-term; systems and habits are for the long-term;
- Involving leaders (both formal and informal) in both brainstorming and implementation makes improvement faster;
- Coaching structure should follow coaching strategy; coaching strategy should follow product/business strategy;
- Sharing work and successes should be intentional, not just organic.
-
keyboard_arrow_down
Anand Bagmar - Eradicate Flaky Tests
45 Mins
Demonstration
Intermediate
Have you heard of “flaky tests”?
There are a lot of articles, blog posts, podcasts, conference talks about what are “Flaky tests” and how to avoid them.
Some of the ideas proposed are:
- Automatically rerun failed tests a couple of times, and hope they pass
- Automatically retry certain operations in the test (ex: retry click / checking for visibility of elements, etc.) and hope the test can proceed
Unfortunately, I do not agree with the above ideas, and I would term these as anti-patterns for fixing flaky / intermittent tests.
We need to understand the reasons for flaky / intermittent tests. Some of these reasons could be because of issues like:
- timing issues (i.e. page loading taking time)
- network issues
- browser-timing issues (different for different browsers / devices)
- data related (dynamic, changing, validity, etc.)
- poor locator strategy (ex: weird & hard-wired xpaths / locators)
- environment issue
- actual issue in the product-under-test
In this session, with the help of demos, we will look at the following techniques you can use to reduce / eliminate the flakiness of your test execution:
- Reduce number of UI tests
- Use Visual Assertions instead of Functional Assertions
- Remove external dependencies via Intelligent Virtualization
Demo will be done using the following and sample code will be shared with the participants