Sustainable pace is an early Extreme Programming concept that was intended to protect programmers from going on “death marches” to meet deadlines that are arbitrary or unmeetable. By abiding by the “sustainable pace” of 40 hours per week and capping our work days after eight-hour “burns,” we could strike a balance of productivity that would not taper off. In this state, we could continue to deliver high quality software at an acceptable rate, without external pressures forcing us to burn out.

However, that statement is like saying the speed limit stops us from drag racing. There may be some correlation, and definitely a coherency of values between that ideal and our work habits, but rarely is there causation. Sometimes craftsmen will need to work longer hours to deliver software of the highest quality. Sometimes, capping our productivity at 40 hours just forces us to create a different arbitrary finish line instead of discovering a natural stopping point for delivering clean, high quality code.

At the core of this concept is the reality that every piece of software is in a race against its own futility. The more we expand our code base and add behaviors and dependencies around it, the more we risk exposing poor decisions that we made earlier on in the project. If we unknowingly introduce a bug to a system, then every layer we add to our system afterward is infected by the same bug. If we architect our code in a certain way, we might struggle to bend it to accommodate unexpected changes in the future.

In many ways, software imposes myopia. We can rarely predict which decisions will come back to haunt us. By doing the simplest thing that could possibly work, we’re exposing ourselves to the incidental complexity described in Ben Moseley and Peter Marks’ paper “Out of the Tar Pit.” Even those decisions that seem very harmless and intuitive are subject to inherent dependencies brought about by things as basic as the language we’re using.

The best defense we have against these shortcomings is to approach every decision with a clear mind and refreshed perspective. If there is a way to think differently or more critically about a decision, we should embrace the opportunity to do so. The sustainable pace is designed to keep our minds in this nimble state. This pace is just a benchmark though, and it doesn’t account for the myriad variables that affect your ability to produce high quality software from 9 to 5.

Sustainability

The idea of sustainability assumes that resources are finite but cyclical. When you exhaust some amount of a resource, it can replenish itself only after a similar investment in its restoration. Clouds can’t pour down rain forever—they require time and cooperation from other parts of the ecosystem to restore their capacity for water. The same is true for your attention levels.

Little tugs and pulls in the quality of your work happen all the time, even over the course of a single day. Right before lunch, you might be struggling to focus on your work instead of the sandwich you’re about to eat. If you eat a big lunch, you might feel sluggish for a little while and incapable of producing the highest quality code. Conversely, if you drink a cup of coffee, you might feel a rush of energy and work at an elevated rate that compensates for the aforementioned shortcomings.

Whether you’re feeling sluggish or energized, you’re likely to feel pressure from others that will force you to respond in different ways. You might get called into a meeting that takes you away from your work for some time. You might get distracted by a coworker who has a question about another part of the system. The product owner might have a different opinion about how you should prioritize your work, and that might impact your ability to deliver a feature.

These variances are natural, but they also represent inefficiencies in our workflow. When we’re sluggish, we’re not reaching the benchmark that sustainable pace was meant to protect; when we’re locked in a groove, we’re likely to over-perform.

Over time we expect these variances to balance out to an average pace that is sustainable. We estimate the work required to deliver features based on this average. However, if we think about our productivity like an ecosystem and find ways to control for these swings, we can improve our sustainability and produce high quality software at a more consistent rate. By taking a holistic view that considers external pressures and the effects they have on our energy and motivation, we can also avoid some basic traps that make ecosystems volatile and unsustainable.

Volatility

One great example of an inefficient ecosystem is our financial system, which suffers from wild swings in both positive and negative directions. Just as something builds up to its peak value, the bottom falls out and it plummets well below its true cost. This downfall is an overreaction, and the price will eventually climb back up toward a true value—somewhere between these two extremes. This return to form is often slow though, and only reinforces the damage caused by the system’s volatility.

This is a similar effect to what happens when developers go on a death march. A team will be determined and push themselves to work extremely hard, and will reach a peak “speed” before collapsing. They will fall into the productivity trap, in which their initial work velocity allows them to continue feeling productive after their output has begun decreasing in quality. It will take much longer to remove themselves from their narrower focus and recover from their exhaustion. In all likelihood, they will have to go backward to correct for some short-sighted decisions they made when they were beginning to burn out.

Avoiding the death march is a great first step, but our workflow shouldn’t need to suffer through radical swings for personal reasons, either. We can tighten the swings above and below the benchmark of sustainable pace by normalizing the environment that surrounds our workflow. We can get better rest at night, and eat a diet that replenishes the proteins and oils our brains need without sitting too heavily and affecting our motivation to perform. There are countless other ways to maintain a positive and productive mindset that remains relatively constant, but many of them are personal to each individual. Our goal should be to create a working environment in which we can write high quality software without exhausting all of our resources and requiring lengthy periods of downtime to restore our abilities.

Drift to low performance

Another trap comes from the gradual decline of quality over time. Many ecosystems, like our carbon emissions, suffer from something akin to the subtle drift to low performance. The amount of pollution we emit changes with the seasons, but throughout the course of a year we are always consuming more carbon than our environment is capable of replenishing; and contributing more pollution than our environment is able to cleanse.

The swings are not radical—or even sometimes noticeable. These slight variations can come when we promise small improvements on a feature in addition to the planned work for the following week. We want to do what’s best for our clients, and sometimes that means doing a little extra. However, over time those small additions that seem negligible will slowly add up to a big weight of technical or feature debt. We will be struggling just to keep up, and the quality of our code will reflect that.

The opposite of this trap is to be steadily improving. The better you understand and manipulate your swings, the higher your valleys become. It’s not as difficult to rebound to writing high quality code. Over time, this will normalize. When the worst you produce is high quality code, you have the opportunity to innovate and expand in new ways. You can train yourself to be able to work harder, longer. You can replenish your energy levels while still writing code at a high level.

Conclusion

Sustainable pace was Extreme Programming’s solution to the short-sightedness of over-working ourselves to meet a deadline. The goal was to make sure everyone has the energy to take her or his time and think through every problem thoroughly, minimizing the likelihood of adding bugs and vulnerabilities to a system. The faster we go, the more likely we are to lose sight of the broader impacts our decisions can have.

However, sustainable pace is defined individually. Each craftswoman or craftsman has her or his own threshold at which quality reduces, and it even changes with the level of engagement on the problem. Certain activities are more exhausting to me than others, and I need to be conscientious of that when scheduling my days. It is important to take the time for reflection and self-measurement to know where these limits are.

As a society, we’ve observed a decline in productivity after 40 hours. Some of us are able to go longer without observing a negative impact on either our work quality or quality of life. However, it’s still important that we keep our work habits in check, because oftentimes we won’t realize our productivity is fading until we’re entirely burnt out. In this case, 40 hours is a good benchmark to stop and self-reflect on your energy levels and attentiveness. Is your productivity remaining stable, and are you continuing to make intelligent decisions? I have rarely seen the type of exhaustion that reduces quality at 40 hours, but it is still a useful measuring stick to be able to reference.