Part of me wonders if git exists as part of a broader experiment to see how long it takes different types of software engineers to hang themselves given virtually endless rope.

America needs more unions” is an understatement.

“And I was worried that “lazy” or bad workers could take advantage of union protections to stay on the job.”

We need to get over this idea that we don’t deserve nice things so long as bad apples exist.

The Cost of Certainty

Paying more often doesn’t come with a clear benefit so why not get the cheap option that is often good enough or even just as good as the more expensive alternative? For example, my wife and I needed a pitcher for a picnic so we just bought one on a whim from the local Duane Reade. I can’t remember the exact cost, but it was definitely under $20 and may have even been under $10. Let me tell you, this discount pitcher from the corner pharmacy is strong, decent looking, and even has two spouts — one if you want to pour with ice and another that keeps the ice inside. This pitcher has also lasted. The picnic was around six years ago, and we have moved several times since.

This is a good pitcher.

But given some time and the mandate to buy a “good pitcher”, I probably would have never bought this one if not for the immediate necessity. I am the type of person who won’t buy anything without at least some research. I would have looked at several options, even attempted to find reviews, and knowing myself, I would have also spent a little bit extra not to get the cheapest one.

Why do all of this? Why even waste one minute for a lousy pitcher? Why not just buy the cheap option?

Certainty.

I want confidence that the thing I am buying will successfully do whatever it is I am buying it for, and I am happy to pay for it in time and/or money. That may seem silly in the context of a pitcher, but consider the ways a pitcher can fail.

  • The lid may not seal well.
  • The water may taste funny.
  • The plastic could easily warp or crack.
  • The clasp may be a pain to open and close.

I don’t know which is worse, buying a failed pitcher that needs immediate replacement or a terrible one that technically “works”. So yeah, I would happily invest time and money to get a good pitcher.

Here’s the thing though, certainty is not binary and nothing is 100% a sure thing.

A highly recommended pitcher that everyone loves might not work for my needs. The recommendation could be for an outdated design. The manufacturer may have just switched factories leading to some new problem. I could simply end up with a lemon. At best, research and spending are just strategies that would merely improve my odds of not ending up with a crappy pitcher. Furthermore, increasing my time and money would eventually result in diminishing returns. The first five minutes of pitcher research are more valuable than the next five minutes (and so on and so on). At some point, the cost of research alone will outstrip the risk of just buying a pitcher from the corner pharmacy.

Certainty in Software Development

The company I work for is currently practicing SAFe Agile. SAFe stands for “Scaled Agile Framework” (I honestly don’t remember where the “e” comes in.) While I won’t go into too much detail, one of the main concepts of SAFe is the program increment or “PI” for short. The SAFe website describes it as follows:

A Program Increment (PI) is a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems. PIs are typically 8 – 12 weeks long. 1

Our program increments are 10 weeks broken into two week iterations (SAFe’s parlance for sprints), followed by a one-to-three week Innovation and Planning Iteration or “IP”. The planning part has been beneficial, especially on totally new ideas that need more thought and detail. Additionally, planning helps identify external team dependencies that can lead to team changes or better alignment between teams. That said, our IPs have gotten so heavily weighted toward planning that it’s bled into the fifth and even fourth iterations of the prior PI.

Why so much planning?

As with many other software methodologies, SAFe deals heavily with making commitments. The business wants product and engineering to commit to certain deliverables. In other words, the business wants certainty. But committing to work 10 weeks ahead of time is really, really hard. So we plan. A lot. That sounds awful and it kind of is, but planning around 10 week commitments has led to more predictable delivery2. The business as a whole enjoys higher certainty, but there’s a cost.

The mental energy and effort that goes into planning invariably comes at some cost to executing. SAFe planning in particular also involves a large amount of logistics in addition to designing and scoping. For example, does team X have enough people to accomplish commitment Y, and/or should we re-scope the commitment to something more achievable? Planning around commitments can also lead to an anti-pattern wherein failing to meet commitments results in more planning, which further eats into execution, which can make failing to meet commitments more likely3. Worse, the added weeks of planning will result in ever diminishing value all while steadily increasing the costs. Finally, the value of planning will vary from project to project. Large projects with isolated unknowns typically have a higher ceiling for planning than small or nascent projects that require more research4.

Remaining aware about the cost of certainty is important and not always easy since it varies from one situation to another while the desire for certainty largely remains the same. I want certainty regardless of whether I am just buying a pitcher or promising a new major feature, but as with anything else I have to be mindful of the cost, value, and risk involved. Sometimes weeks of planning is more than worth it. Sometimes it’s better to just run out and buy a damn pitcher.


  1. Just want to note that the SAFe site hijacks paste to include some sort of scary copyright jargon. Seems counterproductive given the goal of adoption. ↩︎

  2. Your mileage may vary. ↩︎

  3. Regardless if you are using SAFe or not, if commitments aren’t being met, the painfully obvious solution is to simply do less. ↩︎

  4. Because if the focus on commitments, SAFe planning can easily squeeze out inherently uncertain, but potentially valuable ideas that are too nacent to be committed. My team has turned to liberally using SAFe Spikes to specifically explore new ideas. I strongly recommend it. ↩︎

Many processes assume development is like an assembly line where value is added neatly in succession. In my experience, development is more like a pusher game. Value doesn’t always come out and it’s often unclear what exactly happened even when it does.

While I feel like major macOS updates have gotten faster/easier, supposedly minor updates involve a significant time commitment. Maybe these two things are related, but I’d love to see the latter improve with the next “no features” release.

Had a great time meeting @manton and everyone at the IndieWeb Meetup. See y’all next month.