Terminology matters: let's stop calling it a "sprint"
source link: https://ntietz.com/tech-blog/terminology-matters-stop-calling-sprint/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Terminology matters: let's stop calling it a "sprint"
Wednesday, April 29, 2020
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.
Recommend
-
28
容器术语实用导论（A Practical Introduction to Container Terminology）
-
72
Mozilla plans to change the terminology that Firefox's built-in Screenshot Tool uses to describe save and upload actions.
-
45
Amazon Translateis a neural machine translation service that delivers fast, high-quality, and affordable language translation. Today, we are introducing Custom Terminology, a feature that customers can use to customize A...
-
27
README.md
-
17
Artificial intelligence as a discipline consists of hundreds of individual technologies, concepts, and applications. These terms have become increasingly important as STEM education expands and there is a boom in practica...
-
14
It’s not waiting for someone to be “offended.” It’s about why anyone would be defensive about clinging to terrible terms based on horrific inhumane things. Let’s just fix this, finally. And yeah, right...
-
19
It’s been 20 years since MySQL Replication was introduced in MySQL 3.23.15 (Released in May 2000). Since then, virtually every MySQL Database deployment in production has been using Replication in order to achieve high ava...
-
17
Linux 5.8 Formally Adds The Inclusive Terminology Guidelines Written byMichael Larabel inLinux Kernel on 11 July 2020 at 06:38 AM EDT.4 Comments
-
36
-
6
Let’s Stop Calling it “GGX” May 6, 2022 Fifteen years ago, Walter et al. published a fantastic paper...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK