DevSecOps Engineer, Author, and Mentor

While working on adrctl, I found myself needing a small piece of functionality that was useful there but was not inherently about Architecture Decision Records: substitute caller-supplied values into text.

adrctl needed that capability in two closely related places:

• users should be able to define patterns for ADR filenames;
• users should be able to substitute values into ADR body templates.

Both cases involve text containing named tokens that need to be replaced with values. That is also how Nat Pryce’s adr-tools handles ADR templates. Since one of adrctl’s goals is compatibility with adr-tools, existing templates using bare tokens such as TITLE, NUMBER, DATE, and STATUS needed to keep working.

I looked at several libraries and template engines. They were capable tools, but most did considerably more than I wanted. I did not need a programming language hidden inside a template. I needed predictable text substitution with a very small semantic surface.

So, mktext was born.

Read More

While working on my upcoming book, Getting Started with Architecture Decision Records (ADRs), I demonstrated Nat Pryce’s adr-tools tooling. Nat’s tool is truly excellent and I’ve been using it for years. It’s a Bash shell script that can be used to quickly create and maintain ADRs in a Git repository.

As my needs evolved, I found a little place here and another place there where adr-tools didn’t quite align with my needs. For example, adr-tools has a shell script driver plus a bunch of libraries for individual commands. Don’t get me wrong, I love a modular, extensible approach! On the other hand, it meant having to clone or track a small repository of files, not just a single script.

The filenames adr-tools used for ADRs worked well until I encountered a project whose naming convention conflicted with them.

So, a new tool was born: adrctl!

Read More

Few phrases frustrate me as much as, “Because that’s how we’ve always done it.”

The phrase sounds like an explanation, although it provides no reasoning. It asks the listener to accept a practice because the practice already exists. The people who made the original decision may be gone. The conditions that shaped it may have changed. The risks, constraints, conversations, and rejected alternatives may have disappeared from memory. All that remains is the conclusion.

That is how a decision becomes a tradition.

The problem is not that old decisions are necessarily wrong. Many were thoughtful responses to difficult circumstances. The problem is that a future team may inherit the action without inheriting the reasoning. Once that happens, the organization no longer knows whether it is preserving a wise safeguard, repeating an obsolete compromise, or following a habit whose purpose disappeared years ago.

An Architecture Decision Record, commonly called an ADR, helps prevent that loss.

An ADR captures a decision at the moment it is made. It records what the team knew, what remained uncertain, what constraints mattered, what alternatives were considered, why one option was selected, and what consequences the team anticipated. An ADR preserves enough context for someone in the future to understand the decision as more than an unexplained instruction.

That distinction matters.

Read More