The "no-technical debt" challenge

The Context

I arrived 2 months after the beginning of the project

• 2 developers
• already setup React SPA with a lot of SAAS (Cloudinary, etc ..)
• High quality product design
• many many features: Project management, ACL, Planner, Messenger like chat, media theater view, high resolution media upload, medium like note editor, etc ...
   
• ➡️ 6 months deadline, rush time

The "no-technical debt" challenge

The problem

Everything starts from an observation from my experiences

That became a personal obsession and
           by chance a challenge of my company:

Those startups were all “post-fundraising”, almost of the same size (20–50 peoples), dealing with same issues, performance, quality and velocity

Take the right technical choices to support the business,
without neglect the technical roadmap

The "no-technical debt" challenge

"Technical debt" term clarification

Debt is a deliberate decision to implement not-the-best solution or write not-the-best code in order to release software faster.
If you make bad solutions and are not aware of bad code you write — that’s not a technical debt, that’s just a bad architecture.
It is not a debt if you are not aware that you took it.

Speed in Software Development, Michael Dubakov

The "no-technical debt" challenge

It's all about taking the right architecture choices

Build an architecture capable of redeeming the technical debt in a glance.

The Product requirements

How to handle real "technical debt"

Performance

Quality

Velocity

➡️ 1. Quality, 2.Velocity, 3. Performance

Translated to Architecture Quality Attributes

How to handle real "technical debt"

• Modifiability
  Ability to introduce new features, refactor
   
• Maintainability
  Ability to onboard new developers, scale the code
   
• Performance
  User perceived performance

The starting point

How to handle real "technical debt"

• React + TypeScript
  ❌ Maintainability, types missing everywhere
• REST API, local custom redux cache
  ❌ Performance
• React components with bad naming
  ❌ Maintainability
• Complex generic class based components
  ❌ Modifiability, Maintainability
• Complex generic "models" with cache system
  ❌ Modifiability, Maintainability

Background work, technical roadmap

How to handle real "technical debt"

• Maintainability / Modifiability

  • keep dependencies up to date

  • no any: typing everywhere

  • Components Single Responsibility Principle

  • Immutable data

  • remove classes, especially inheritance

  • Routing
     

• QA

  • Test coverage
     

• Performance

  • GraphQL API

  • drop redux

Guidelines for new development

How to handle real "technical debt"

➡️ Enhance Modifiability, so :
reduce module size, increase cohesion and reduce coupling

- React components naming convention

- Redux as event-bus

- Components SRP

- Data HoC in order to prepare GraphQL migration

React components naming convention

How to handle real "technical debt"

The GraphQL migration anticipation

How to handle real "technical debt"

View Component

REST HoC

View Component

GraphQL HoC