The Fallacy of Productivity in Software Development
By: Albert Kozłowski
Tags: Leadership, Programming, Software Development, Productivity, Startup

Startups and the Myth of 10X Developers

Especially in their early stages, startups work in a different way than mature organizations. Most startups not only build products by borrowing money, but they also take on technical debt. For them, delivering MVP quickly is essential, as early validation is absolutely required.

This is the culture that gave rise to 10X developers. Like protagonists in action movies, these mythical developers can single-handedly beat up ten normal teammates in terms of productivity — or so the legend goes.

In real life, the so-called 10X developers are most likely cowboy coders — sitting alone in hoodies with their headphones on, working on a codebase only they understand.

Limited interactions and cooperation within teams only work as long as the codebase and the team itself remain very small. While sometimes these teams can deliver more than those at a more mature organization within the same time frame, it is often done at the cost of quality. After all, there is no such thing as a free lunch.

Unfortunately, the situation is not much better even in mature organizations. Collaboration is often limited to code reviews, and if you are lucky, you may also run into occasional pair programming sessions or bigger meetings.

Don’t get me wrong, code reviews are great! However, it’s hard to apply major changes once work has already been completed — not to mention that big changes are often ruled out due to tight deadlines. Chances are that the review will mostly focus on syntax, naming, and other simple changes.

Nowadays, when working with distributed architectures (micro-services, Lambda, cloud-managed services, etc.), there are thousands of possible solutions to every problem. DevOps and the cloud took away some of the burden of managing physical servers, but they also increased the complexity of software interactions (queues, APIs) and the amount of planning required.

Cooperation is imperative in order to create long-lasting and high-quality code. Having quick brainstorming sessions on the whiteboard before starting tasks could potentially help teams save a lot of time. Yet many developers still prefer to work in isolation, causing them to receive the first round of feedback during the code review, which is already problematic.

I often saw junior developers being afraid to distract senior colleagues and even waiting a day or more to ask a single question. While this often comes as an individual preference, there are also environmental reasons that make rapid cooperation harder.

Here are some of the ones I have personally encountered:

Open-space office

At some point, open floor plans became the go-to choice for software companies. These new and shiny spaces promised increased communication between teams, but in reality, they forced people to start using headphones to cancel the noise around them. Consequently, it also discouraged teams from doing rapid brainstorming sessions for fear of disturbing others. Some could argue that the often available (yet limited) enclosed meeting spaces could be used. However, pulling entire teams away to discuss small changes would certainly be considered overkill.

Agile, sprints, lack of idle time

Nowadays, most organizations have adopted some sort of Agile/Scrum methodology. Sprints are usually packed with tickets to the brim, leaving literarily zero space for the team to be in idle mode or even have time for discussions. The end of sprints resembles crunch time, with people pushing their work as fast as possible to make the burnout charts look as required. In an environment where there is a constant two-week deadline, it is hard to make the work stop even for 15 minutes and drag the team into any sort of discussion.

Management

Having a group of people smiling, discussing, and doodling on a whiteboard might seem like fun — even too fun for some. In an environment where people are often passionate about their work, it is easy to get caught in an engaging architectural discussion. Unfortunately, this is something that often gets mistaken for goofing around by non-technical management.