In the wake of recent Twitter staff layoffs, we explore why taking the path of code simplicity is vital for tech industry productivity.

With all the furore around the Twitter layoffs — including rumours that the “Chief Twit” himself Elon Musk has laid off technologists based purely on the lines of code submitted (which are almost certainly not 100 per cent true) — we’ve seen an old wound reopened. The perennial conundrum of “how should we measure developer productivity?” has reared its head once again.

However, should we be going even further, and asking more pertinent questions like “should” and “how” do we measure developer productivity, and exactly “who” should be measuring it?

When measures cease to be any good

History has shown that lines of code, number of bugs fixed, etc. are an example of Goodhart’s Law — “when a measure becomes a target, it ceases to be a good measure” — in action. When companies have taken this route in the past, it has led to aberrant behaviours like creating bugs just to fix them, or bloating the code-base.

At the root of this whole controversy, it shows that executives often don’t really understand software engineering and the value that engineers (especially more experienced ones) bring to the table. This is not piecework; we’re not stuffing envelopes or shipping parcels (not that there’s anything wrong with this kind of work). It’s a creative and problem-solving process where less can sometimes be much more.

Keep it simple, stupid!

Many times, in my days at the code-face, I’d spend my evening removing lines of code from the solution to make it simpler, easier to read and maintain. Because the simplest solution, as long as it meets both the functional and non-functional requirements, is often the best one.

Add to this the fact that tech is expanding so rapidly that many problems are already solved, and it becomes a case of selecting the right existing solution, rather than actually writing the code.

Take your hands off the keyboard for a moment

I often say that I’m happier with hiring people to not write code. Why? Because there’s a lot of important considerations to make before you start coding, and you’ll likely end up at risk of adding to the problem.

Here’s a list of questions I ask myself before I start coding, and I encourage others to do the same:

• Do you understand the problem you’re trying to solve?

• Has this problem already been solved?

• Do you understand the constraints of the solution, design and patterns you’re working in?

• Do you understand the implications of what you’re about to write in the code-base?

• Do you understand the implications outside of the code-base (3rd parties etc.) of your change?

• Can you write this without making the code-base larger?

• Can you keep it as simple as possible (KISS)?

• Do you need to refactor anything first?

• Can you get this piece to meet the Definition of Done?

• Are you mentally ready to solve the problem?

• Have you thought about the tests, hopefully writing them first?

• Does it need to be written now?

• Does it need to be written at all?

This filter, albeit wordy, can help a software engineer do the simplest and least work. In many cases, the solution already exists, so choosing an off the shelf, SaaS or open source solution is the most sensible approach. They all lead towards improvements in things like quality rather than quantity metrics, and this is where I believe we should be focusing; on the quality of the solution.

There’s also “unplanned work” (or technical debt, which is a much-maligned term, and necessary refactoring). Often in engineering, we need to spend time cleaning up the campground in order to make future changes or enhancements sustainable. In Kent Beck’s immortal words: “For each desired change, make the change easy (warning: this may be hard), then make the easy change”.

Less is often more

Remediating a code-base may not add features, and may indeed shrink it. You may end up with something that on the surface doesn’t really look like much. However, it’s the ethical and sustainable thing to do in many cases. For instance, if you look at some of the more critical activities we do as engineers, many of them do not involve writing much code, such as security, scalability, performance and reliability. If you discourage these activities and meanwhile fuel a culture where code laid down equals value/productivity, then you’re going to find yourself in a pickle pretty quickly.

The old argument is that “not everybody needs a Rolls Royce solution”, which is true when you talk about leaving off the plush carpets and walnut dash. But I hope we can agree that we don’t want, and shouldn’t be able to omit seatbelts from our cars. This is where, as engineers, we need to be fierce and brave, protecting the quality of what we produce, as that almost always has the knock on effect of also protecting productivity.

How we should be using metrics

If anything, developer productivity metrics should be for the development team as an aggregate (to understand team dynamics), and for the individual, so they can work on their own productivity, tracking collaboration, time spent online, personal velocity, time spent waiting for reviews, etc. These are not a stick to beat people with, but a way of using data to fuel continuous improvement both personally and within teams. They are not for execs to fire people by, or to judge people’s performance and progression. But there are other things we should be considering when it comes to developer “productivity”, like time spent coaching and mentoring, pairing, reviewing, contributing to inner or open source projects.

As an individual, we’re single-threaded; even a 10x developer can only do so much in a day, but by growing others, we can multiply our ability to deliver quality products at pace. Twitter may lose their top talent over this situation, and as an industry we should be taking some learnings from the ongoing debacle. The most important lesson we can glean is this: to strive to measure the right kinds of things, for the right kind of purposes. And finally, no printouts please, we’re not charging by the kilo here. Jeff Watkins (https://www.linkedin.com/in/jeff-watkins-5167111/) is chief product and technology officer at xDesign.