There’s an anecdote that stands out in the world of software development, one that echoes the differences between incremental progress and transformative leaps. It’s a race: one participant walks, another takes a train, and the third, a plane. Their progress is a lesson in perspective.

The walker makes consistent strides, moving forward little by little, much like the methodical approach of incremental software updates. The train traveler waits and then makes a relatively rapid journey, similar to software teams that release features in batches. But the individual who chooses the plane? First, they seem to go in the opposite direction, much like a developer considering an overhaul or refactoring of a codebase. Then there’s the waiting, representing the time investment required for such an undertaking. Yet, once they take off, their progress is unparalleled.

In the software realm, this anecdote aligns with the debate between refactoring and incremental improvements. Refactoring – the act of restructuring existing code without changing its external behavior – might seem like a detour. In the short term, this can appear as if development has halted or even regressed. But this is an investment. Once complete, the refactoring can lead to a more streamlined, efficient, and maintainable system, much like the rapid journey of our plane traveler.

On the other hand, the steady path of incremental improvements, akin to the walker’s approach, offers a different kind of value. There’s consistent and visible progress, a safer route where outcomes are more predictable. But the potential for transformative leaps is not as pronounced as with refactoring.

The Deception of Metrics

A critical point of reflection in our industry is how we measure progress. Metrics in software development can be, and often are, deceiving. Whether it’s story points, sprint goals, bets, t-shirt sizes, or any other inventive metric du jour (acorns, anyone?), these measurements often capture effort but not always impact.

The walker’s journey, filled with steady steps, might tick off many metric boxes, often appeasing decision-makers with the illusion of consistent progress and predictability. However, the plane traveler’s initial backward movement and waiting time might not score well on conventional metrics, even if they are eventually set to make a massive leap forward. This is an essential lesson for tech leaders and teams: don’t let conventional metrics blind you to the potential advantages of taking a step back to leap forward.

The Worst Programmer

Similar lessons can be applied when building a team. Traditional performance evaluations often hinge on tangible outputs and easily quantifiable achievements. But innovation, creativity, team synergy, and problem-solving abilities often go unnoticed. These are elements that might not always translate well on paper, but they can significantly influence a project’s trajectory.

For instance, an individual’s capacity to foster a collaborative environment, ask critical questions, or see the broader picture can be far more beneficial than the ability to quickly produce lines of code. These soft skills can be pivotal in preventing groupthink, promoting diversity of thought, and driving the team towards optimal solutions.

So, before hastily labeling someone based on a metric-driven assessment, it’s essential to recognize and appreciate the myriad of ways in which team members can add value. Because sometimes, paradoxically, your best employee, the one who challenges the norm and brings a fresh perspective might just be the worst programmer you know.