Engineering teams at TableCheck have different guidelines on Friday deploys. Some do it, others have guidelines that discourage it. New joiners or junior engineers often receive different signals. “Bob told me it was okay, but Lisa said never to do it and to read the docs first.” Why does receiving instructions have to be so confusing? Friday deploys are actually a great lens through which to understand the nuanced art of decision-making as a software engineer.

The Booking Experience Squad at TableCheck typically adheres to a “no Friday deploys” policy. As TableCheck’s main clients are restaurants, it is critical that our systems are reliable when restaurants are at their busiest: Friday evenings and weekends. Restaurant staff are busy preparing for the dinner rush and weekend, and will not have the bandwidth (or patience) to deal with an unreliable system when they need it the most. Of course, there are exceptions. I have had my fair share of hot fix deploys at 11 p.m. to put out a fire for an important client before they went live with our product. (Tip for engineering managers: take your QA team out for drinks).

So in general while the policy is to avoid Friday deploys, there is precedent for Friday deploys and sometimes we do deploy on Friday for the sake of velocity. So why is there a policy if it is sometimes ignored?

First Principle #1: "With great power comes great responsibility"

This freedom to ignore the policy isn't carte blanche; it's paired with the responsibility of a weight equivalent to the change being deployed: we must be held accountable for changes we wish to deploy. This accountability extends beyond the Friday deploy policy. If someone is considering deploying a substantial change at 8 p.m. on a Friday, by all means, they are allowed. But if something goes wrong, the deployer is responsible for putting out the fire. So, have common sense with deploys. It is not wise to deploy unapproved, untested code in the middle of the night when the rest of us are sleeping.

If we now understand that the policy is flexible, why is it even a policy?

First Principle #2: "As simple as possible, as complicated as necessary"

RELATED: Engineering – First principles

I’ve spent an entire paragraph explaining the flexible nature of the policy. This flexibility comes with the added burden of cognitive load. Every time a developer needs to decide if they should deploy on a Friday, they’re going to have to think about the tradeoffs. Having a strict policy removes the cognitive load from developers and makes understanding the deployment policy as simple as possible with no added complexity/flexibility.

With a flexible policy, what can we learn about the art of decision-making in software engineering?

First Principle #3: "Beware of false dichotomies"

RELATED: Wikipedia - False dilemma

The question “Should I, or should I not deploy on Friday?” is a false dichotomy, there is no easy yes/no answer; it depends on various circumstances, nuances, and the policy itself.

Some might argue that a hardline stance against Friday deploys can make life simpler. True, but the flip side is that if you live every moment of your life in your comfort zone, you will not grow. To experience discomfort is to grow. The benefit of personal growth through challenge is not explicitly written into any deployment policy I have seen, and yet it is a real side effect we should consider.

At its core, software engineering is the process of making difficult decisions with incomplete information. As engineers, we should strive to improve our hard technical skills as well as our ability to understand the trade-offs and future implications of any given decision to move forward with high velocity.

First Principle #4: "The only constant in life is change”

Business priorities change, and companies grow and evolve. Maybe you need to pivot from a “move fast and break things” policy-free mentality to a more rigorous policy of stability, reliability, and quality that might even be legally bound to service-level agreements.

Let’s synthesize the first principles we’ve learned: the best engineers are (1) true to their word and hold themselves accountable, (2) able to keep their systems as simple as possible and only as necessarily complex as per the given requirements of the business, (3) able to see past false dichotomies and deeply understand tradeoffs of any decision, and (4) rapidly adapt their policies and systems to new requirements.

Finally, let's contextualize what we’ve learned about decisions and tradeoffs through the career ladder we have at TableCheck for software engineers:

• Junior Engineer: "I barely understand the problem, and I’m not even aware of how many tradeoffs there are or their possible implications."

• Engineer: "I understand the problem and have identified a number of tradeoffs, but I need a guiding hand to make the best decision."

• Senior Engineer: "I understand the problem and its root technical cause. I can quickly pick the best decision without any help."

• Principal Engineer: "I deeply understand the problem, have seen something similar in other domains, and can choose the decision that should prevent this problem from happening in the future."

So, the next time you contemplate a Friday deploy, think about what you can learn from the decision-making process itself.