Developer Productivity @ Scale

There are multiple ways to scale

When it comes to scaling, most developers assume there is only one way to scale: performance. How do I support the most number of users, or the highest amount of traffic, or the fastest processing times?

The above is what I consider Performance @ Scale.

But there is another way to scale: rate of development. Can my rate of development keep up in a sustainable way over the long-run.

This is what I consider Developer Productivity @ Scale.

Complexity is your biggest throttle

There is a well-studied concept in software development called technical debt. In this concept, a code base accummulates hacks (“expedient solutions”) over the lifetime of its development, and unless investment is made to reduce it in the course of development, it accummulates and eventually causes the project to stall.

I have seen this happen multiple times in my career:

• A poorly documented critical frontend code base with three different coding styles and an equal number of state management libraries. A third of features were covered by test cases, half of which failed anyway on the main branch. This led to an incredibly high turnover rate, and stalled project delivery.
• A developer that took a nested if-else requirement, and turned into it a complex switch statement built out of bitwise-operations. This, and other similar decisions turned a 6 month project into a 1 and a half year project.
• An attempt to shoehorn IdP provider flows in a single-sign-on feature into a password-based authentication setup. This one we caught in time, but would have been a ticking time bomb for security vulnerabilities and an obstacle to effective handover.
• I cursed and swore at a series of unreadable functions that no one could understand, only to realise I myself had written it 2 weeks ago, and therefore was swearing at myself.

Each of the above added complexities, that throttled (or would have throttled) development in the medium to long-run.

A fictional burndown visualisation