On average 41% of developers time is spent on technical debt

by Tom Wilson

In 2018, Stripe released a study called the developer coefficient. The report concluded that software engineering efficiency would cost 3 Trillion in GDP over the next ten years.

There are lots of great information in the paper, if you have time, you should take a look, but one statistic stood out for me as a developer.

On average, 41% of developer's time is working on bugs, maintenance, and technical debt.

As developers, you are most likely nodding your head in agreement or saying at my place of employment, it is more like 60% or 70%, or it should be because our system is drowning in complexity.

Some teams are known as high performing teams that regularly spend less than 20% of their time dealing with technical debt. How?

  • At some point in the project, they implemented firm boundaries between their systems, separating standard services from application business logic.
  • Implemented automated, resilient test coverage
  • Implemented automated lifecycle deployment
  • And automated software lifecycle metrics

Guess what? Without the first bullet, the next three are very hard to implement. There are plenty of buzz words about architecture styles, and preferences and those are excellent patterns for the specific use cases. Regardless of technology or architecture design, if you do not separate your business logic and rules from your implementation details, you will reach a point where the technical debt takes 41% and above your developer's time. As a result, the developer culture becomes an unproductive environment for most developers.

hyper63 is a service framework that creates a firm boundary between your business logic/rules and your services (implementation details) so that development teams can focus on the work that drives value into the business.

Whether you use hyper63 or implement service boundaries on your own, convince your team as early as possible to think about how developers should organize the application code so that you don't let technical debt become the bottleneck to your productivity and developer happiness.