The Creative Developer Deadlock (Why Efficiency Isn’t Everything)

In an interesting book called Technopoly, Neil Postman evaluates the invention of the stethoscope with a degree of criticism that we are not custom to in modernity.

Namely, Postman asserts that while the stethoscope is a tremendous technology that has increased doctors' success, it is not without its big-picture consequences — and those consequences are worth considering.

The stethoscope, and medical instruments like it, shifted the role of a doctor from depending primarily on the symptoms of the patient to depending primarily on the results of an instrument.

Sure, a good doctor will still carefully discern a patient’s symptoms in addition to using instruments to gather metrics to help make sense of those symptoms. In such a case, technology is used to improve upon former human processes.

However, what happens if we become obsessive with efficiency and technology supersedes human experiences? Using our example of medical instruments, what happens if efficiency so animates doctors that the instruments begin to be trusted over and against the subjective experience of the patient? This would be bad doctoring.

In a word, efficiency is not everything. It may be more efficient for doctors to rely solely upon instruments than a patient’s symptoms but hyper-efficiency is checked because we tend to intuitively know that good doctoring requires attention to the subjective human experience. Technology may make for more efficient processes, but those efficient processes should also be checked from going overboard and harming human interactions rather than aiding them.

Sure, one could counter this abusus non tollit usum. True, but we should still be concerned about the abuse, and in some cases, the abuse is more common and intrinsic than we realize.

Technology is a broader category than we think. For example, assigning a letter to a grade is a type of technology that helps educators systematize reporting a student’s ability to learn and apply knowledge on a particular subject.

Likewise, when it comes to the space of software development, Agile is a type of technology whereby developers can (in theory) more efficiently plan, execute, and evaluate the release through smaller phases of development.

Applying an Agile approach, software teams are usually structured in a common way.

There is a product team, led by a project manager, that interacts with customers and brainstorms the future features to be released to customers for a software product; there is also a designer who helps to translate these features into prototypes that developers can then implement in actual code.

The batch release of features is grouped into a project, or epic, and the work is broken down into individual stories that describe the criteria of what developers are to develop based on small, tight product requirements and designs.

Stories are then brought into sprints which represent the lifespan of the planning, executing, and evaluating stories within an epic. Developers sprint to accomplish the tightly defined chunks of work (stories), and then, the product team and developers sync up to evaluate the sprint and plan for the work to be done in the next sprint.

This Agile technology allows for more frequent reviewing and planning of development which increases product-developer communication to break past deadlocks, miscalculations, deficiencies, etc. It is a technology that helps teams build software more efficiently and safely.

However, like medical instruments, it shifts how an industry works in ways that are not always discerned, and hence, the big picture consequences can fall off the radar all because of hyperfocus on efficiency.

In this case of Agile technology, in particular, the software development industry has largely shifted to working in teams that are organized in such a way to promote ultimate efficiency. The end goal of these teams becomes to release software cycle after cycle.

It is indeed a red flag of hyper-efficiency if our model for software development tells developers to sprint endlessly without any consideration for inevitable fatigue.

The bad doctoring that is seen too often in Agile circles is that developers are on a hamster wheel of ceaseless feature delivery (with few exceptions) all because we are putting so much emphasis on the Agile instrument.

The wave of sprinting ought to include periodic opportunities for rest, and so, we must: how is it that developers rest?

Developers are rested and ready to sprint (energized) only when they are developing their craft as much as possible.

Agile teams are structured from the assumption that feature delivery is the be-all and end-all of software development teams. That may be the desired output for the set of product people and developers from the vantage point of the business. However, for most developers, this is not the end goal from their vantage point.

Developers may find feature delivery for a given product interesting but not ultimate in their ambitions. Rather, their focus is ultimately on developing their craft — at least the more mature ones (junior developers tend to focus solely on knocking out stories, but that quickly creates fatigue).

So, without an emphasis on having developers develop their craft, developers will not be rested, and hence, they will not want to endlessly sprint — and if they do, they will lose steam (or velocity). Ironically, this means that setting up teams to be as productive as possible to deliver features actually makes teams less productive in the long haul.

It is not as simple as an instrument or no instrument — technology or no technology. We must carefully discern.

An attentive analysis would indicate that creative developers struggle the most on Agile teams. By creative developers, I mean those developers that care more about their craft than their product. Those developers tend not to be junior, and so, they tend to be the more intelligent and productive developers (when rested).

But, as mentioned, they are not always rested because Agile teams are centered around building a craft but building a product.

What are signs that a developer is not rested (besides a not-always-telling metric like velocity)?

Usually, a creative developer is itching to make their repetitive work more…well, creative. They want to incorporate new design patterns, technologies, processes, etc. They get really excited about designing a new API but not so excited about building the same thing again.

Perhaps an easier rule thumb is this: creative developers are the ones that don’t work like factory workers—those developers that mostly care about finishing stories, follow all the criteria laid out by someone else verbatim, sit in the passenger seat on discussions about code quality, and don’t seem as phased by constant feature development.

Now, this is no offense to factory workers in the literal or figuratively-applied sense. Everyone is called to different types of work requiring different degrees of knowledge and skill. All work is valuable and should be applauded by all. Life would be difficult without factory workers, but that does not mean that everyone is called to be a factory worker.

Even within software development, developers are gifted for different types of work, not all requiring the same degree of knowledge, skill, and creativity.

When we fail to distinguish the creative developers from the factory workers and throw everyone indiscriminately on the persistent lifecycle of sprinting, we hit a deadlock.

The creative developers will be fatigued from the lack of creativity. And so, as I have seen before, more creative, aspiring developers will eventually give way when deadlocks are reached.

What’s the lesson in all of this? Technology may increase efficiency, but we have to discern beyond short-term efficiency. Applying that principle to Agile technology, we should discern the consequences of potentially being hyperfocused on feature delivery, causing creative developers to reach a deadlock.

So, what can we do? Perhaps that can be taken up in a follow-up, but for now, suffice it to say that we should be emphasizing the end goal of developers — the development of their craft —as much as the efficient output of the product-developer team. Maybe then we will boost efficiency for the long haul.