Surprisingly Universal Things Learned from Software Development

I once ran a software development team. This was an amazing group of people who cared deeply about working as a cohesive team and doing awesome things. This was wonderful, of course, but as a manager I found that sometimes their dedication led to crazy all-night caffeine-fueled coding binges, working weekends, skipping vacation days, and more. And that just sucks. I don’t want people doing that. So, I always told them to go home and cut it out. Unfortunately, I’d get a lot of “yeah, yeah”s, and then I’d catch them working a weekend anyway. (If you’re paying attention, you’ll realize that means I was there on the weekend, too. I didn’t learn the nuances- or the danger- of “leading by example” until a bit later on, but that’s another blog post.)

One interesting thing I noticed in all this is that it was usually in these over-working situations when we also released code with all kinds of problems, or various standards “violations”, or it just outright didn’t work. Which, of course, resulted in the QA manager standing in my door and saying various disparaging things about my organization, many of which I could never repeat to my mother.

So, I say to myself, “Myself,” I say, “something here needs to be fixed.”

So, I wrangled all of my software engineers into a room, ordered us some lunch, and we sat down, elbow to elbow, and came up with some rules. These rules turned into a series of questions that became known as the “Release Gate”, and any engineer wanting to release his software had to pass through that gate, or be thrown into the Pit of Despair (“red… no! blue!”). Ok, I kid. They just couldn’t release their software unless they could pass the gate. But the Pit of Despair thing is funnier.

The fascinating thing is that we were all really trying to solve the “QA manager wants to push us in front of a bus” problem, but we wound up fixing many of the work-life balance problems as well. It was surprising initially, but, looking back, it makes total sense.

Software Team Release Rules

Before we get into the details, it’s important to know some foundational elements of the Release Gate:

• Everyone agreed, as a team, that the questionnaire was an important part of our process, so we had full acceptance that we would utilize it.
• We all believed that failing was acceptable but failing alone was not. There were few things that could turn a release conversation from a positive to a negative, but one thing that we kept an eye on was communication. Problems that could have an impact on the release needed to be brought to the team’s attention as soon as they were discovered.
• It wasn’t so much a “pass/fail” thing, as the two people assessing an overall health and risk profile of the intended release. I don’t like binary decisions. The human element is important. The point is for the humans to talk and make a good decision together.

Now, for your perusal- and hopefully enjoyment- here is a summarized version of the Release Gate questionnaire:

Software Release Delivery Dates are Negotiable, Quality is Not

The question: “Are you releasing because the product is ready? Or are you releasing because you have to make a date? Do you feel like you are rushing?”

The reasoning: Most of the time, dates are set by people who don’t understand the process of ccreating a product very well, don’t understand the subtleties between “goal dates to motivate teams towards completion” vs. “hard line dates to enforce”, are driven by internal or external forces with “other motivations”, or all three. People generating the product are constantly under pressure to meet deadlines that are almost always arbitrary and the result is often undesirable. Plus, the first one to complain, after the QA manager, is likely the one who was driving the team with a bullwhip all along. Go figure.

The unexpected results: We wound up having more and more reasonable and informed conversations with the product management team, and management in general, about the potential impact of releasing something that wasn’t quite ready. This helped educate the other teams around us and gave us a far better understanding of the business and its needs. It also developed better cross-organizational relationships and eased the process of ensuring that future releases would not only more likely be “on time”, but higher in quality as well.

Your People are More Important Than Anything

The question: “Were you working on this past 6 PM last night, before 8 AM this morning, or over the weekend? Are you feeling alright and without stress?”

The reasoning: People working at ridiculous hours are not only compromising their personal lives and just generally doing all kinds of bad things to themselves, but are also working at a diminished level, which leads to quality issues that make everyone miserable. And, as I said before, that just sucks. I had to stop one guy who was actively wrecking his marriage over some arbitrary work commitments. I’m sorry, but that’s just crazy. No way. No, no and NO.

The unexpected results: My team members started to grasp that I wasn’t going to let them release their code if they were doing bad things to their personal lives to make some arbitrary release date, so it would be pointless for them to kill themselves working insane hours to try. After over a year of me trying- and failing- to get people to please stop working and go home, it turned out that establishing a seemingly weird rule was the thing that actually fixed the problem- and pretty much overnight.

Accurate and Quality Records are Always Critical

The question: “Is all of your code checked in? Is it properly commented? Did you fill out the release documentation?”

The reasoning: The product is never complete until someone else can theoretically re-create it from the documentation you leave behind. That is a tall order, but it’s the measuring stick that my team used when they decided if something was “done”. Yes, it meant we had a sixty-some-odd page document on our engineering practices and many of our major releases included as many pages or more in requirements, engineering specifications, release notes, and beyond. However, each time we had to refer back to our documentation to remember why we did this or that, the answers were always there. And every time we had to crack open the code to make a change, the code was always there. Even when someone had to suddenly go on leave for a health issue, we were able to have someone else pick up the torch and keep running with it.

The unexpected results: This approach let us do some unheard-of things surprisingly easily. We established an “exchange program” where a person from QA or operations could take a hiatus from their usual duties and work with us on our team to engineer a new release of a product (one of my team would usually fill in their spot in the other organization). This had a second-tier unexpected result of furthering the improvement of our relationship with these organizations, because, well… partly because we each understood the other’s job and challenges a lot better, but mostly because it meant we spent time with each other. And life is all about relationships and empathy.

But I’m not in software development!

Yeah, I know. But the point of this is it’s not really about that. Think through a couple scenarios of different jobs that likely are not yours, and how that might affect the end result. What would happen if you let any of the following people rush to meet a date when the end product was bad, work too much to try to make the date anyway, or fail to ensure accurate documentation or record their work:

• Meat packer
• Short order cook
• Limousine driver
• Rocket scientist
• Nuclear power plant inspector
• Whatever it is you do for a living

I genuinely hope you can quickly come to at least a few pretty obviously scary conclusions on any of those. I know I certainly did. And that wasn’t even getting into the fact that all these people could very well be your neighbor, your friend, your spouse, or your child… and that just makes it all the more poignant in my mind. I hope it does in yours as well.

Contact us if you would like to know more or need help strategizing within your own team.