Is technical debt really technical

Technical debt 
(also known as design debt or code debt)
is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now, instead of using a better approach that would take longer.

Common causes of technical debt

• Insufficient up-front definition…
• Business pressures…
• Lack of process or understanding…
• Tightly-coupled components…
• Lack of a test suite…
• Lack of documentation…
• Lack of collaboration…
• Parallel development…
• Delayed refactoring…
• Lack of alignment to standards…
• Lack of knowledge…
• Lack of ownership…
• Poor technological leadership…
• Last minute specification changes…

Source of the debt

Ignorance debt \ Role-overriding

Insufficient up-front definition

•Requirements are still being defined during development, development starts before any design takes place.

•This is done to save time, but often has to be reworked later.

Lack of process or understanding

•Businesses are blind to the concept of technical debt, and make decisions without considering the implications.

Lack of collaboration

•Knowledge isn’t shared around the organization, business efficiency suffers.

•Junior developers are not properly mentored.

Delayed refactoring

•As the requirements for a project evolve, it may become clear that parts of
the code have become inefficient or difficult to edit and must be refactored,
in order to support future requirements.

•The longer that refactoring is delayed, and the more code is added, the
bigger the debt.

Agility debt \ Mercantilism

Business pressures

•The business considers getting something released sooner, before all of the necessary changes are complete, and builds up technical debt – comprising those uncompleted changes.

Lack of a test suite

•Encouraging quick and risky band-aids to fix bugs.

Lack of documentation

•Code is created without necessary supporting documentation.

•The work to create any supporting documentation represents a debt, that must be paid.

Last minute specification changes

•These changes have potential to percolate throughout a project, but no time or budget to see them through with documentation and checks.

Leadership debt \ Lack of departments

Poor technological leadership 

•Poorly thought out commands handed down the chain of command increase the technical debt, rather than reduce it.

Lack of alignment to standards

•Industry standard features, frameworks, technologies are ignored.

•Eventually, integration with standards will come, doing sooner will cost less.

Lack of ownership

•Outsourced software efforts result in in-house engineering being required to refactor or rewrite outsourced code.

Real Technical Debt

Tightly-coupled components

•Functions are not modular, the software is not flexible enough to adapt to changes in business needs.

Parallel development

•Development on two or more branches accrues technical debt because of the work required to merge the changes into a single source base.

•The more changes that are done in isolation, the more debt is piled up.

Lack of knowledge

•The developer simply doesn’t know how to write elegant code.

How to avoid technical debt

D.I.Y.

•Architecture before development

•Communication and onboarding

•Self-training

•Documentation (Blog)

Perfection

•Marketing and Business – respect your engineering role

•Proper chain of actions

— — Requirements gathering, case studies, PoC, estimations before contract

•Leadership and RACI matrix in place

•Architecture Standards, Guidelines and Governance

•Respect to the documentation

•Personal development plan with trainings and conferences