On Sustainable Software Development

July 11, 2020

The Hulk action figure

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 and stay up to be part of the Raleigh NYE celebration (which, features an acorn drop at midnight).

Instead, I was hunched over my computer. I was manually verifying the last of our billing statements were ready to go out. The past day had been an exhausted one. Every process had gone wrong, 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.

It wasn’t fine that we were keeping this system afloat by sheer willpower.

Software Development Shouldn’t Be Heroics

How many of you have worked on a team that always had to be putting in “heroic work” or were always “stepping up to the plate” in 11th-hour situations? Were it was normal 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, and their achievement is hailed as “grit” or “great work.” If they miss the deadline, though — they are scolded for not making the deadline and wind up working just as long to get it done when they can.

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 in this state of frantic overwork, something is just plain wrong. They aren’t building the right software. They aren’t investing in the right places. They aren’t having the correct retrospectives with themselves or with product owners.

Something needs to change.

Development Should be Sustainable

One of the core principles behind the Agile Manifesto is this

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Its often an overlooked one too. Why?

I believe it’s because teams that embrace all the other principles — continuous delivery, short iterations, prioritizing developer efficiency, etc. — leads naturally to a sustainable pace. It also means that if a development team is doing those things well, there can be useful estimates from the team about when they can complete work. This makes product owners happy as their job of predicting features to users, and setting direction for the product is now more straightforward.

However, many teams only think they are following the other principles when in reality they are chasing their tails. And if they don’t remember the principle about sustainable pace, they will never realize they missed the others.

I also think there is a slight tendency for developers 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 that we are doing something meaningful.

I’m not condemning hard work at all! I am simply saying 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?

I’ll be blunt: it won’t be simple or easy. Chances are you will find that there is push back from not only the product owners or managers but even push back from the team. Teams who 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 towards sustainable pace requires a few things:

  1. Admit the team is overworked. This is harder than you might think. Some developers don’t want people they work long hours because they are afraid it means they will look inadequate (i.e., “You had to work the weekend to finish that simple task?”).
  2. 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.
  3. Identify from your 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.
  4. Keep doing that over and over!

It sounds too 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 also hard to follow. It takes real work and a commitment to change for a retrospective process to make an impact. 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.