Understanding and how to manage development technical debt for IT departments

1. How To Manage and
Reduce Development
Technical Debt
By Abdul khan
https://www.linkedin.com/in/abdul-khan-uk/

2. Author
• Abdul Khan
• IT Consultant based in Manchester, UK
• Engineering Lead, Executive, Technologist, Architect
• IT experience, within the private and public sectors (Retail, Banking, Digital, Insurance, M.O.D., HMRC, Aviation, Telecommunication,
Housing Associations, Education, Travel, and Pharmaceutical companies). Excellent architectural and strong DevOps experience with
proven-track record of delivering E2E, B2B and B2C solution on regional and global programs.
• SME in specializing in providing integration, data migration, digital transformations to the cloud solutions (Azure and AWS)
• Wealth of experience in global projects across EMEA, ASPAC and LATAM
• Liked in profile https://www.linkedin.com/in/abdul-khan-uk/

3. Accreditations
Thank you to my brother, good friends and colleagues for reviewing, adding value, sharing their vast experience
and knowledge.
• Samad Khan (IT Manager), specialising in enterprise solution in finance and wealth Management
• Steve Langton (IT Consultant, Cloud SME) specialising in NetOps, DevOps and SecOps
• Phil Eaton-Dykes (IT Consultant) 30+ years experience in enterprise solutions

4. Audience
Main Audience
• Managers
• Product Owners
• Technical Managers
• Architects
• Technical Leads and Engineers

5. How to Manage and Reduce
Development Technical Debt

6. Content
1. Presentation Objectives
2. Presentation Scope
3. What Is Development Tech Debt?
4. Development Technical Debt Taxonomy
5. Development Technical Debt Domains
6. Development Technical Debt Cycle
7. Managing Development Tech Debt
8. Development Tech Debt that effects your team
9. Development Tech Debt that damages business
10. Development Tech Debt that damages your business
11. Development Tech Debt that prevents business growth
12. What is Reckless Debt?
13. What Causes Development Tech Debt?
14. How to Reduce or Eliminate Development Technical Debt
15. 7 Sins of Managing Development Technical Debt
16. Management of Development Technical Debt
17. Other Tech Debt
18. Final Thoughts

7. 1. Presentation Objectives
• To understand what is Development technical debt
• How to manage Development technical debt

8. 2. Presentation Scope
Overall IT Technical Debt
Development
Technical Debt
Infrastructure Technical Debt
=In scope of the current presentation
Out of scope.
This is covered the next Infrastructure
Technical Debt presentation pack
Complete Technical debt

9. 3. What Is Development Technical Debt?
Development Technical debt is pretty much any code anyone wrote
last week. It’s all around us, binds us, and basically duct-tapes-and-
glues the tech world together. Tech Debt is a part of life and, while
we all want to ensure all our code is perfect and lasts the test of
time, you will live with Tech Debt. Some Tech Debt needs to managed
and reduced immediately, and some does not.

10. 4. Development Technical Debt Taxonomy
Overall IT System Technical Debt
Architecture Debt Document Debt Testing Debt Coding Debt
Technological
Gaps

11. 5. Development Technical Debt Domains
Architecture
Code Level
Testing
Documentation
Technological Gap
Business Goals and Objectives
Use cases Diagram
Processes
Business Architecture (BA)
Business Functions/Services
Business Roles
Business Data Model
Functional Decomposition
Business Data Model
Data Management Process Model
Data Interoperability
Data Architecture (DA)
Data Entity/Business Function Matrix
Application Portfolio Catalogue
Application/Organization Matrix
Role/Application Matrix
Application Architecture (AA)
Application/Function Matrix
Application Interaction Matrix
Implementation Guidelines
Implementation Specification
Implementation Standards
Interoperability requirements
IT Service Management Requirements
Technology Standards Catalogue
Technology Platform and decomposition
Environment and locations
Technology Architecture (TA)
Expected processing Load and Distribution
Physical (network) communications
Hardware and networks Specifications
Application/Technology Matrix
Technical Debt Domains
Sub Types of Architectural Technical Debt (TD) Types
TOGAF Deliverables
Technical Debt (TD) Types`

12. 6. Development Technical Debt Cycle
Which lead to …
Poor Practices
• Quality of Coding
• Design of application
• Infrastructure
• Poor practice (communication,
review, documentation, handover) Frequent Incidents
• Application my break regular
• Time and tasks planned for projects
instead spent on fixing incidents
Touch & Go
• We don’t apply durable and robust
solution as we are under pressure
to fix and build more.
• Skills & training is limited
• Confidence is low
• Moving targets and priorities
Which means we are
increasing…
Low Recoveries
• High Levels of incidents / break/fix
lead to high levels of BAU
• Meeting & email culture uses up a
lot of time
This will lead to …
More work required,
hence additional work is
required on incidents…

13. 7. Managing Development Technical Debt
• Define and understanding your business categories of development technical debt and how to linked to the
business strategies.
• Development stack and tools should be mapped to long term IT road map, priorities id tools, languages,
resources and software life-cycle is key. Its also important to consider managing Tech Debt e.g. what to address,
what to ignore and for how long.
• While we don’t get everything right all the time, ensure that there is a deliverable product road map and keep a
sustainable, pride worthy pace of innovation. As this could be a game-changing outcome of addressing the right
tech debt at the right time that will drive and support business goals.
• Building features and addressing underlying platform/tools/quality needs are absolutely necessary
requirements for any technical manager. But there is a lot more to see under the covers here.
• Construct a plan to Identifying, articulating and lobbying to remove these obstacles in time
• The results of development tech debt planning will clearly support the business growth and prompt confidence
across the organization and, most importantly customer satisfaction.

14. 8. Development Technical Debt That Effects Teams
Consider the following :-
• Does the team deliver on the roadmap on a good schedule?
• Are they all tired because they are all literally “working all the time”?
• Do you have data to figure out why they are working all the time?
• Is it because the deadlines for new features are unreasonable?
• Or is it because the time/resource cost of supporting your existing service went up while you
weren’t looking?
• These are the “soft” signs that this type of debt is at play and needs to be addressed before it
graduates to the killing-your-business kind, they are:
• Incidents that had to be addressed in any given week – this should be stable number
• Repeat incidents – did the same thing happen last week?
• To manage technical debt it is important to gather hard data around the debt, diligently conduct
retrospectives after every critical issue in production, identify what went wrong and break it down
into bite-size chunks that you can address along with the rest of the sprint work.
• For some short period of time, you may have slower progress on the feature roadmap, but progress
should not stop and the delay should still be within reasonable schedule variance. Addressing this
type of tech debt will yield value immediately and will set up future success.

15. 9. Development Technical Debt That Effects
Businesses
“Your current solution could be great while the business was small but in the current climate the solution can’t
handle the load or it’s just not isn’t fast enough” this is serious tech debt problem.
• New systems can benefit and grow businesses, also learn from mistakes and build tech that essentially stack.
This is the easiest type of debt to prioritize, but usually the hardest to resolve.
• Something that has been around for years and if it was easy to address you would likely have addressed it
already. Resolving this type of tech debt will require you to sacrifice significant portions of your product
roadmap. So, while this one might be the easiest to build up, as a tech leader who wants to make money, you
want to take steps in advance to avoid this kind of technical debt like the plague.
• As you build new features, you should not forget what is wrong with the older features you are carrying around.
Pay attention to the things that are holding you down. As an example, for us at Conductor, our old Monolithic
application was built in Java 6, and the intricate web of dependencies that evolved over time made it a drag for
us to upgrade, address scale issues, improve performance, etc. We are explicitly applying the strangler pattern to
all new development, with the ruling mantra of being able to independently build/deploy/test/scale anything
new we build. Hard-earned learnings from the past will explicitly be part of our success in the future.

16. 10. Development Technical Debt That Damages Businesses
• Some tech debt can be a blocker for growth for your business. Your product may be working fine right now but
the future needs of the business may qualify some portions of your solution as debt. This debt is only debt if you
foresee it blocking your growth in the future. That future tech debt might be portions of features that were never
implemented because no one got around to it for whatever reason. Over time, that not-yet-implemented
functionality can became a sinkhole that many things might fall into. Some examples:
• A new feature got added many years ago for the domestic market, but there wasn’t high demand to make it
available in the international market, so it never got added there. Over time, this gulf just grew to be so
large that it started to affect business. In addition, the cost of addressing it became exponentially larger.
• An ETL pipeline that gets kicked off on a schedule works really well until you change the time zones and
address customers who are awake when you are asleep or vice versa. Since the time zones were not
something you had to think about before, going back and addressing this now can be costly or based on a
new implementation.
• Hardcoded content and values
• Not all of this debt needs a technical solution, and it can be a discussion between multiple departments Do a lot
of due diligence and ensure you absolutely have to have a technical solution. If you need it, build it into the
roadmap.

17. 11. Development Technical Debt That Prevents Business Growth
• This type of debt is the hardest to make a great business case for. It’s the type of debt that I believe tech
leaders struggle with the most, and for good reason. This is the kind of debt that results from thinking, “if we
just had a standard platform/api/pattern, we would be able to move so much faster.”
• The technologist in all of us wants to build a platform that is sufficient and robust and scales for all the
features that are built using it. This is an eternal struggle and the benefits of adding another layer of
robustness to this platform is never a clean cut decision. It is always partly supported by empirical data and
partly by extrapolation. This is the type of debt that is hardest to quantify because it isn’t really killing your
business now, it isn’t killing your team, and it isn’t going to kill your business next year. As a leader, this is
what you spend your political capital on.
• Calculate the opportunity cost and doing a SWOT analysis, the future benefit of addressing this debt now is
greater than the future of adding another feature or fixing more bugs.
• Build a plan and start executing on addressing the issues. The lack of flexibility in this configuration will
significantly limit our ability to innovate next year in feature areas that are already in early discussions in the
Product team, with the industry leaders and with our expert users.

18. 12. What Is Reckless Debt?
“Reckless Debt is code that violates design principles and good
practices.”
In short this means, that all code generated by us and our team is junk (not done on purpose of course).
Moreover, Reckless Debt will lead to Technical Debt in the short/mid term and it is also a signal that your team
needs more training, or you have too many inexperienced or junior developers.

19. 13. What Causes Development Technical Debt?
• Poor Conception:
• When developing an application, the speed at which the team or the company delivers the product can make a real
difference, after all, an application or software is developed to answer a particular problem or to address a specific
challenge in a timely manner. The rush in delivering faster often results in poorly designed software, not well thought
out, and development is mainly focusing on developing the functionalities.
• Poor Scheduling:
• Underestimating during the software development estimation process often causes technical debt. A development
team's focus is on the respect of time estimates and is accumulating lots of bad practices that they will ultimately have to
pay.
• Bad Development Practices:
• It is crucial that the development team has a set of practices and conventions so that there is a little or no significant
difference in design and implementation from feature to feature. A lack of development good practices and conventions
will lead developers to implement their design, rebuild the same logic over and over, and format their code the way they
want rather than the way it is commonly accepted in the particular software project.
• Outdated Technology:
• As technology evolves, software standards become higher every day. With each improvement, new technical debt can
arise.

20. 14. How to Reduce or Eliminate Development
Technical Debt
• The Quickest to Solve:
• Fixing debts that take little time to fix is an excellent way to eliminate technical debt gradually. Debts like code
formatting can be solved in a little time, making up a template and apply these templates to all the codes that have
been developed so far, then integrate these templates in the tools used by the developers.
• Priority:
• It is also important to address issues by priority. All issues that can lead to more significant issues should be addressed
quickly and should be prioritized to avoid accumulation.
• Technology Update:
• When outdated technology leads to technical debt, it is important to update the software to the newest versions of the
frameworks, application servers, databases etc. It is even important to include every stable evolution of a framework
used for instance to always have the latest update and to bring small change without breaking the software.
• Refactoring:
• Reviewing the software architecture and refactoring codes often can be useful when we don't want to end up with
duplicate code or codes that lack modularity.

21. 15. 7 Sins Of Developments Technical Debt
(Don’t) Reinvent the wheel
Unit Tests
Acceptance Tests
7. Pride
Software Metrics
Documentation
Not Using Version Control
No Features Required
Contributions To Open Source Projects
6. Envy
Input Validation
Duplications
Code Standards
4. Sloth
Lazy Coding
Self-Development
Configuration “Out-Of-The-Box”
Over-engineering
Refactoring
“Spaghetti Code”
2. Gluttony
Feature-rich
Inefficiency
Over-engineering
Design Patterns
Abstraction
1. Lust
A vehement denial of the truth
Documentation
Coding Standards
5. Wrath
Unit Tests
Commit Messages
Rushing To Production
Computing across teams
Don’t Reinvent the wheel
Power Struggle
3. Greed

22. 16. Management Of Development Technical Debt
Quality Management Plan
Plan Quality
Perform Quality Assurance Perform Quality Control
Testing DebtCoding Debt
Quality Management Plan
Quality
Metrics
Quality Control
Measurements
Quality
Check List
Work Performance
Information
Deliverables
Approved Changes
Requests
Changes Requests
Controlling quality involves monitoring specific results to determine whether they comply with the planned quality standards, which
include project processes and product goals, and controlling the results by taking actions to eliminate unsatisfactory performance

23. 17. Managing Other Technical Debt
• Everything else shouldn’t affect your roadmap commitments. That doesn’t mean you shouldn’t pick up
small/medium things to pick up and address as they arise, but it shouldn’t affect your committed
deliverables and product roadmap. If the debt is important enough, it will reveal itself in time. There is no
magic formula to apply here. You have to let time be your guide and analyse all new pieces of information
and apply intuition.
• Be critical and get comfortable with some debt: it will always be with you in some form. Every once in a
while you will get a surprise present from an engineer because they just couldn’t take it anymore and
fixed something that you didn’t ask for but is the right thing to do.
• Building software is an interesting and satisfying mix of art and science. Therefore, deciding which tech
debt to address will have major impacts on any business. The above rules of thumb have been a huge
contributing factor in building happy, productive, profitable tech teams for the past few decades.

24. 18. Final Thoughts
Having technical debt at some point of the software development process is quite usual. However, managing
technical debt is important to avoid their accumulation over time. This will require the business to accept a
certain amount of technical debt, but ultimately there should be kept at an acceptable level at which they
don't harm the performance and the overall experience of the software product users.
Contrary to the estimation of development time, the estimation of technical debt is based on existing code
that often evolves. It is then necessary to have a good approach to estimate the technical debt included in
the software developed. Due to the ever-shifting nature of the code and the volume of codes to be
evaluated, it is not possible to perform a manual estimation. It is then necessary to work with the right tools
that allow an automatic computation of technical debt estimates.
Although addressing technical debt can cost money, leaving technical debts in software will cost more money
in the future.

25. - END OF DECK
By Abdul Khan – https://www.linkedin.com/in/abdul-khan-uk/