A fine line divides the descriptive from the prescriptive: Observations and predictions become rules we follow, not always for good reasons. This week, we’ll bemoan a few big-picture examples where the distinction has been lost, then talk about how we can do better. First, though, let’s give primacy to two common ways descriptions are mistaken for constraints:
When you try to follow someone else’s lead, and don’t quite get it right, don’t judge yourself too harshly. Don’t let examples or suggestions become molds you force yourself (or anyone else) to fit.
Building something new (or even fixing a bug) means confronting innumerable unknowns. Development estimates are inherently wild guesses, and we should never blame ourselves or each other for getting them wrong. Guessing wrong is neither a moral failing, nor any reflection on competence. The real trick is not calling your shot, but accumulating incremental value even in the face of the unpredictable.
Design Patterns are a case where the line between description and prescription has been blurred. Patterns are, by definition, descriptive. They are never invented; only discovered. Yet some programmers look to Design Patterns as a kind of cookbook, mistaking patterns for recipes, and believing there are right and wrong ways to implement them. Patterns may inspire us, but applying them color-by-number turns a benefit into a burden, destroying creativity and locking us into those cliched boxes we're supposed to think outside of. Patterns are great as shared points of reference, but lousy as doctrine.
A more extreme example is Scrum. Scrum's original insight was that new product development is more like research than manufacturing. We can't put Blue Book values on new features: Our best estimates are only shots in the dark. Scrum addressed this uncertainty by introducing frequent inspection and course correction. Sprint planning was about communication, not guarantees. Nowadays, though, Scrum is mostly rules and meetings dictated by vendors and consultants whose payment is independent of project success. The Harvard Business Review article that originally proposed Scrum back in 1986 presciently calls out the peril of mistaking description for prescription:
In today’s fast-paced, fiercely competitive world of commercial new product development ... institutionalization, when carried too far, can create its own danger. Passing down words of wisdom from the past or establishing standard practices based on success stories works well when the external environment is stable. Changes in the environment, however, can quickly make such lessons impractical.
The Agile Software Development movement has suffered a similar fate. The Agile Manifesto explicitly values “Individuals and interactions over processes and tools,” and “Responding to change over following a plan.” In the decades since the movement was born, though, Agile has come to mean just the reverse: It's mostly about selling software that gives second-line managers the illusion of insight, and making engineers do busywork (however well intentioned) that has nothing to do with engineering. If that sounds harsh, imagine how crestfallen the authors of the manifesto, like Dave Thomas, must be. Better yet, watch his 2015 presentation, Agile is Dead.
None of this means prescriptivism can’t be valuable. The Art of Computer Programming, for example, is a work of pure instruction, as beautiful as it is useful. Knuth’s algorithms aren’t mere descriptions or estimates, but specific approaches that get results; and he can prove it.
Here are a few suggestions to help you avoid mistaking “how things are done” for “what you must do:”
Distinguish prescriptions from descriptions. When somebody tells you “that's how we do things here,” know whether they're instructing or only observing.
Get rules in writing. If necessary, write them down yourself, then solicit written confirmation or correction. Circulate such codifications as widely as possible to make sure they accurately reflect your team’s (or customer’s) intent. Keep them in a shared location, so your entire group has a Single Source of Truth for all guidelines from coding standards to company values.
Understand incentives. Know who wrote the rules, and why. This comes up not only with vendors and consultants, but in large organizations where someone’s promotion may depend on internal adoption of a particular tool or process. Any rule whose author is not personally accountable for its consequences should be viewed askance.
If you disagree with a rule, and it matters to you, propose changes. If you have ethical concerns, report them. At the end of the day, we are each responsible for our own actions, and rules do not absolve us of that duty.
Memoirs of regret or failure, though rarely mistaken for prescription, are worth mentioning before we go. They often embody more humility and less survival bias than success stories, and are thus more relatable and enjoyable, all schadenfreude aside. My 10 Biggest Mistakes as BrewDog’s CEO and Dreaming in Code are good examples, and the book Chaos Monkeys is as entertaining as it is educational. Further suggestions are appreciated in the comments.
fuck. imagine if agile enthusiasts read (and marinated on) the actual manifesto... 🤣
Most so called "Agile Enthusiasts" are folks who used to get CMM and PMI certified and now get Scrum certified. I have interviewed hundreds of Agile Coaches and Scrum Masters and it's abundantly clear who gets it and who doesn't. I have become a huge fan of Josh Kerievsky and his Modern Agile movement, first introduced to me by my friend Jon Kern, one of the OG 12. I personally think that SAFe was the worst thing to happen to Agile. It's really hard to do well and it usually becomes a way for bean counters to have the illusion of control. It's also really hard to do PI planning remotely so I think that the best process in the remote combines some agile practices, along with tools like ProductBoard to give plenty of Real Time visibility to the Product Roadmap. The sequence should be Business Goal -> Design of Initiative -> Sprints/Kanban Queue -> Learning -> Validation against Business Goal -> Iterate and adapt the Initiative or Sprints / Tasks based on learning -> Repeat until done. What many people forget in bastardizing Scrum into Scrumban, injecting deliverables mid sprint was that sprint length was meant to give adequate time for completing work in a linear fashion, giving short intervals to run experiments. I've rarely seen actual Scrum in practice. Most "Agile" is ScrumBanFall - Business/Finance are Waterfall, Product/Eng follow Scrum in planning work, Business injects customer need, which upsets Sprints, excess WIP happens, everyone is confused, Estimates are f*cked, no one is happy, every is confused - did I say that already, most partially completed work needs to be redone, everyone worked harder, but got less done.