The "no-technical debt" challenge

23 march 2018

Charly POLY

  • Tech lead @ A line
  • Software Engineer
  • 25 yo, 6 years XP
  • Previous companies : Dashlane, JobTeaser

💛  What I like in my field

✨ Skills

Problem solving, Software architecture & JavaScript, enhance Business with technical solutions.

Front-end expertise, AWS solutions, GraphQL, Ruby, Rails, SQL/Postgres ... (full-stack)

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.

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

Conclusion

How to handle real "technical debt"

Technical debt is good architecture

Product
requirements

Architecture QAs

Technical roadmap

Technical guide

Features updates

new features

Made with Slides.com