Gwendy’s Morning
Gwendy tucks her hair behind her ears before she returns her hands to the keyboard and finishes typing out a line of code. She’s been working on this particular piece of code since right after standup this morning. It’s probably not a “feature” as defined in the traditional sense. She’s creating a new abstraction that she’ll expose via the REST API – hopefully this afternoon. Gwendy would like to get the code for this abstraction reviewed and merged on its own, though. Even if no one would actually be able to use it, she feels it really helps to get early feedback and integrate with everyone else’s changes often.
Gwendy enjoys the daylight streaming in through her office’s floor to ceiling window. She stares out at the view as she thinks for a few moments before putting the finishing touches on the function and running the tests for her new abstraction. She smiles as her glasses reflect the green check indicating her tests passed. She commits, pushes, and opens a pull request for review. Looking at the clock, she sees that it’s still over an hour until lunchtime. Gwendy’s stomach doesn’t quite agree with the clock. She grabs her water bottle, pushes back from her desk, and heads to the kitchen to acquire a snack and a water refill.
As Gwendy strolls back into her office, she feels the cool, smooth, spotless wooden floors underfoot. She sits at her desk and sees a message from a coworker, “Hey, looking at your pull request now.”
With a nod, she types back, “Great, thanks!” She opens up the repository in her browser and sees a couple of other open pull requests. One happens to be from the coworker that just messaged her. She clicks on it. It’s a pretty simple change – a fix for an edge case in one of the analysis tools. The code change is pretty obviously correct, but Gwendy opens up her browser to the test environment that her coworker set up. After verifying the fix, she returns to the pull request, clicks “Approve,” and closes the tab.
When she goes back to her pull request, she sees a couple of comments. After responding to the first comment, she reads the second one and sighs – she hadn’t thought of that possibility. “Oh well, this is why it pays to get early feedback,” she thinks as she switches over to her editor. It should be an easy fix. Sure enough – after about a half hour of writing another failing test and adding a couple lines of logic, the tests are green again. She commits, pushes her changes, and messages her coworker, “Hey, I updated that pull request you reviewed.”
“Hey, thanks for reviewing mine! One sec,” is the response.
Gwendy stands up and stretches for a couple of minutes before she receives another message from her coworker, “Approved!”
Gwendy checks the pull request in her web browser and clicks “Merge.” She leaves her desk to start preparing an early lunch. She can almost taste the soup and sandwich she’s planning to make.
Before she finishes work for the day, Gwendy merges her API changes and sees them deployed to one percent of customers. The frontend isn’t ready for the changes yet, but Gwendy is able to look at the production metrics for the customers that received the change and make sure that her changes didn’t break anything. She also does some basic testing of the API endpoint using an API client testing tool. It has been a productive day, and Gwendy is satisfied when she finally closes her laptop and heads towards the living room to spend time with her family – just a couple of minutes after five.
Jimothy’s Fortnight
Jimothy wipes the oil from the potato chips he’s been eating on his cutoff jeans. He runs his fingers through his greasy hair as he stares wearily at his screen: currently the only light source in his basement office. He hasn’t showered since the day before yesterday. Jimothy’s been working on this feature for the past couple of weeks, and he stayed up until early this morning to try to get this code up for review today. The item he’s working on is not a feature in the traditional sense. It’s actually more like five features. He knows that he needs to give people about a week to review the code, since he has made a lot of changes. If it doesn’t get merged before the cutoff, then it’ll have to wait another six weeks until the next cutoff.
Jimothy removes his hand from his knotted locks and places it firmly on his crumb-filled keyboard. As he starts typing, he mutters under his breath about how the space bar has never registered correctly on this piece of junk. He’s been trying to get the tests in this test suite to pass for at least an hour now. He hadn’t anticipated that his changes would affect this part of the system, but it’s not surprising due to the extent of his work. An hour later, he finally sees a green check. Light has started to stream in the tiny basement windows as Jimothy commits, pushes, and opens a pull request for his changes. Finally, his chair squeaks as he swivels and stands up to walk over to the old couch in the corner. As he crashes face first onto the sofa, a cloud of dust puffs into the air and wafts through the shaft of light from one of the windows. As he closes his eyes to sleep for a couple of hours – he won’t make standup this morning – he hopes that his builds will be finished when he awakes.
A few hours later, Jimothy wakes up with a start from a troubling dream about failing tests. He groggily rubs his eyes and scratches the back of his neck as he shuffles back over to his computer to check the builds. It looks like all of them passed except one. “That’s pretty good!” Jimothy thinks as he starts to look through the build log. It looks like a failure he’s seen before. He kicks off a rebuild and plods up the stairs to take a shower and eat some sugary cereal – he figures he deserves it after putting in all that hard work.
After his breakfast, Jimothy returns to his computer only to find that the build he re-ran seems to have failed again. Investigating further, he finds that it’s actually a problem with his code this time – another area of the system that he hadn’t thought would be affected. He spends most of the rest of the day updating his code to adjust to the new findings. As he’s about to take off for the day, he checks to see if anyone has started a review of his pull request yet. He sees one comment from a coworker, “I’ll take a look at this tomorrow.”
The next day, Jimothy starts working on fixing a bug for a change of pace in the morning while he waits for some feedback on his pull request. Having gotten a good night’s sleep, some decent food, and a recent shower, things are starting to look up. When he gets back from lunch, however, Jimothy’s heart sinks as he sees the thirty comments on his pull request and the dreaded, “Changes Requested.” Digging in, Jimothy begins to wonder if he’s going to have to rewrite a couple of the abstractions that he designed. Over the next few days of back and forth comments, code changes, waiting for builds, and some more late nights/early mornings, Jimothy begins to realize that he’s not going to make the cutoff. He tries not to let it bother him, but his inner critic makes that difficult. The next week, he finally gets his changes merged, and takes a day off to recharge. When his feature is finally seen by a customer months later, Jimothy has mostly forgotten about it, since he’s moved on to another part of the codebase. Unfortunately, the customers generally don’t even use it. The feature works as intended, but it doesn’t quite address any problem that customers care about.
The Lesson
Obviously, I’ve taken some artistic license here to strengthen my point, but who seems to be more productive – Gwendy or Jimothy? Even without the extra color, I think it’s pretty obvious that Gwendy is more effective at getting things done and ensuring that those things are the right things.
Another question: during your day to day work, who do you identify with more? I confess that there have been days that I’ve felt much more like Jimothy than Gwendy, and it’s not just because of issues with cleanliness. On more than one occasion, I have found myself in front of my computer late at night or early in the morning, “heroically” trying to get something I had been working on for weeks finished before a deadline.
These experiences have helped me form the opinion that the habits and processes that Gwendy follows are more productive, and there is a lot of evidence that supports this opinion. One source of evidence that I’d like to highlight in this article is the 2021 State of DevOps report. This report is based on survey research and explores connections between DevOps practices, software delivery performance, organizational performance, company culture, and many more things. The research approach and the findings are very interesting. If you’re interested in learning more, I recommend first perusing the different aspects of the research on the DevOps Research website. And if you’re interested in even more background after that, I recommend the book Accelerate: Building and Scaling High-Performing Technology Organizations, which describes the research in more detail, including the study techniques used and each of the findings as of the 2017 report.
The techniques from the research that I highlighted in the stories above include continuous delivery, trunk-based development, a clear and lightweight change approval process, working in small batches, and work in process (WIP) limits. There are many others that would be worth discussing, but I brought these up because I think they provide a nice illustration and a healthy mix of processes that are influenced from both the top down and the bottom up.
Continuous delivery, for example, is something that can require significant organizational change, and so must be addressed mostly from the top down. At Seeq, historically we have had a primarily on-premise deployment model. With an on-premise deployment model, continuous delivery is basically impossible because each customer must be involved in upgrades. However, since we are in the process of shifting from primarily on-premise deployments to primarily serving our customers in our cloud-based SaaS offering, we should, in time, be able to take advantage of the benefits of Continuous Delivery.
As another example, trunk-based development is partially supported by top down processes, but it also has a dependency on how individual developers work. At Seeq, we have learned through a handful of painful experiences that long-lived (on the scale of weeks to months) feature branches are a bad idea. So we have formally documented that we discourage the practice of creating long-lived feature branches. But trunk-based development goes even further, recommending that all changes be merged into trunk at least once a day. This requires a lightweight change process that could require some top down organizational change. It also requires that others on the team are supportive of this idea – especially if you need them to review your changes at least once a day (and don’t forget you need to review their changes, too!).
So what can you do today to make yourself and your organization more productive? I can think of two things that should be immediately actionable for anyone who may read this:
- Make sure you are working in small batches
- Share these DevOps principles with your colleagues
Working in small batches should be entirely within your control. Just because your coworkers put up monster pull requests or batch up lots of changes doesn’t mean that you have to. So the next time your making some changes, consider how you could break them up further. Figure out how to do a piece of the solution and get that merged before moving on to the next piece. The other thing you can do to support working in small batches is to strive to be more responsive to your coworkers’ changes that need review. If they have to wait for a day or two to get their changes reviewed, then they’ll be more likely to try to batch up more into the changes so that they’ll all get reviewed at once. Then this bigger batch of changes will cause you to be less motivated to review their changes because you know it’s going to take so long to review them. Then the next time they’ll be tempted to batch up even more changes, and so on.
Once you’ve started improving some of your personal habits, you can start sharing these principles with others. Perhaps a good start would be to share this article with your coworkers. Or perhaps point them directly at the research. Maybe you could start asking people to break up their changes more in the future. There are lots of options to start improving things, and over time these efforts should start to add up to bigger improvements in both your personal productivity and, eventually, the performance of your entire organization.