If you're in the software industry, it's hard to not be aware of agile development at this point. It seems like every team practices it differently, but there are certain commonalities that run through all teams I've seen. One of those is the term used for each time-delimited section of the development process: "sprint."

I'm an endurance athlete, and this term sends shudders through me. Software development is very much akin to an endurance event. You run into similar challenges. When you're running a marathon, most of the work is already done, if you have trained adequately, but there is a lot remaining still to do during the event itself. It's a mental game at that point: you need to have the resolve to just keep putting one foot in front of the other, over and over, over and over, until you hit that finish line hours later. But here's the thing: at no point during a marathon do you -- or should you -- sprint. Sprinting is high effort and high speed and can be sustained for some time, but not for 26.2 miles. If you sprint at any point during the race, then you are decreasing your overall performance, because that spent energy reduces the capacity you have to run the rest of it at your max sustainable pace.

Software development is similar. Our brains are not infinite resources which we can push day-in and day-out. This is why we have to sleep, so our brains and bodies can recover from the toils of the day. It is well known that as we work longer hours, our output gets slower and slower, and that it is able to reach negative returns - so there is a point where working longer hours reduces your total output. It actually does not take very long to reach that point.

That is what is actually analogous to a sprint: something which is so taxing for you to do that it reduces your capacity for other exertion temporarily, which you need to put significant effort toward recovering from. A normal development cycle is not, or should not, be a sprint, because you have to do many of these in a year, over and over, without an end in sight. Even if you leave that team, you will wind up somewhere else where you are repeating these development cycles. It would be better that we call them something else: perhaps a "leg", continuing the running analogy but this time evoking a long journey ("leg of the journey") or relay race.

This may seem inconsequential semantic nitpicking. It is not. The terms we use set expectations for those inside and outside our industry. If you have little other context around how software development works (if you're new to the industry, if you're hearing a relative talk about work) then when you hear "sprint" it will make you think of a high exertion activity, such as you put in at crunch time when you need to just push something over the finish line. Even within our teams, the term shifts mindsets and can justify problems. Most of us have probably been in situations where we justified doing things in a very hacky way since it's temporary, just to shove something forward, "we'll fix it later" (we never do). This is undoubtedly influenced by the terminology we use. Every day we hear the term "sprint." "Next sprint, we'll fix that," we say. "This sprint, we're doing it quickly."

This would all be different - subtly, but surely - if we used a more fitting term. If we called each development cycle a "leg", it could evoke many images but in the context of a journey, would surely shift our mindsets to think more about how this is really just part of our longer journey to create a product, build some features, change the world. It puts the emphasis on this cycle being part of a larger whole. That will change what you and your teams produce, because it raises your consciousness of the long-term impact of what you do.