On Sustainable Software Development
July 11, 2020
It’s 9:45 pm on New Year’s Eve. I was supposed to be downtown a few hours ago with a group of friends to stay up to be part of the Raleigh NYE celebration (which features an acorn drop at midnight).
Instead, I was hunched over my computer, manually verifying that the last of our billing statements were ready to go out. The past day had been exhausting. Every process had gone wrong, and no one was around due to the holiday, but we had to get statements out.
We thankfully did, and everything was fine.
Except it wasn’t fine.
It wasn’t fine that I was still in the office.
It wasn’t fine that I had broken promises to my friends because of work (again).
It wasn’t fine that we kept this system afloat by sheer willpower.
It’s been many years since that experience, but now more than ever, I stand by the idea that writing software shouldn’t consistently require heroics for the job to get done.
The Software “Heros”
How many of you have worked on a team that always had to be doing “heroic work” or “stepping up to the plate” in 11th-hour situations? Teams on which it was common for team members to work late, over the weekend, or skip lunch—or all three?
These teams usually get praised if they hit the deadline. Their achievement and work ethic are touted as the kind others should aspire to. If they miss the deadline, though, they are scolded for not making it and told to get it together.
While these situations are nearly inevitable — every team will hit some form of crunch time that requires some extra work — it should not be the norm. And it shouldn’t be seen as heroic work.
When teams are constantly overworked like this, we must stop praising their commitment when they hit a goal. We need to start reevaluating the culture, the code, and the process that leaves them in this state all the time. It could be that the team or company isn’t making the right investments, that the product owner isn’t managing their road map properly, or that someone on the team isn’t pulling their weight.
Whatever it is, something needs to change.
Development Should be Sustainable
One of the core principles behind the Agile Manifesto states this
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This principle properly elevates software developers and their stakeholders for what they are: humans. Developers, product owners, etc., aren’t just cogs in the machine churning out code for the faceless business owner to profit from. Humans have finite capacity and can only be pushed so much.
Sadly, this principle is overlooked. Why is that?
This principle is forgotten because it often affects the other principles in the manifesto. Teams that embrace ideas like continuous delivery, short iterations, prioritizing developer efficiency, etc., will naturally find a sustainable pace because much of the toil is automated, and many of their daily decisions are simplified.
However, many teams only think they are following the other principles when, in reality, they are chasing their tails. If they don’t remember the principle of sustainable pace, they will never realize they missed the others.
I also think developers have a slight tendency to want to be perpetually busy. There is a false sense of meaning that comes from always being busy, isn’t there? Our whole society says that if we are busy or hustling or continually working, we are doing something meaningful.
I’m not condemning hard work at all! There are more meaningful things than working long hours to fix a bug on New Year’s Eve.
How to Get There
How does one take a team that regularly feels up against the wall or behind and create a sustainable cadence?
While the steps are simple, actually taking them is challenging. Chances are you will find pushback from not only the product owners or managers but also from the team. Teams that have lived in this “hero” world might start to think they won’t get noticed or that they won’t be needed. Change is hard.
In my experience, getting onto a path toward a sustainable pace requires a few things:
- Admit the team is overworked. This is harder than you might think. Some developers are afraid to admit that they work as much as they do for fear it will make them look incompetent (“You had to work the weekend to finish that simple task?!”).
- Start holding a retrospective. It doesn’t need to be an hour long, and it doesn’t need to be every two weeks. Heck, you don’t even need a big meeting to start. Create a shared document and pass it around, asking team members to add things they would think the team should keep doing, stop doing, and start doing. After a day or two, share the feedback during your typical standup or set up a 15-minute summary.
- Identify via team retrospectives one thing — yes, one thing — to try. It could be starting something, stopping something, investing in a system, etc. Just pick something you think will help your team.
- Keep doing that over and over!
It sounds so simple, right? The truth is that this process is simple. It’s a framework for the team to own something they think will make them better. Given that chance, most engineers will go to things that will improve their codebase and their lives overall.
It’s just hard to follow. It takes work and action from everone on the team for this process to be effective. Everyone needs to commit to the process, and everyone needs to be honest about their opinion.
Before wrapping up, consider your team’s “one thing” for a retrospective to define what constitutes an emergency and what does not. Define if there are cases in which someone needs to work late or over the weekend to complete or when it can wait till the next workday. This definition is important because it will help your team get out of the feeling of perpetually being against the wall.
Development shouldn’t be a constant state of exhaustion and hero programming. We need to work together as teams to create sustainable workflows that allow our teams to build software effectively for the long haul.
I hope this guide helps you and your team!
Happy coding!
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.