Doc Norton
Don't fail fast; Observe often

The problem with "fail fast" is that it too often becomes "move fast." Failure is hidden or spun as success, speed is rewarded, and the learning part gets lost entirely. At its worst, "fail fast" is an excuse to rush into the next thing without pausing to understand what just happened.

What I want to promote instead is Observe Often. The shift in language is intentional—when we say “observe,” we bring focus back to what matters: seeing, measuring, and learning from what we do. And “often” reinforces frequency over haste. It’s not about reckless speed; it’s about small, deliberate moves and frequent feedback loops.

Don't fail fast; Observe often
Doc Norton
Why I Joined Test Double

When I say I’m joining Test Double as their new VP of Delivery, I’m not just making a career move—I’m making an alignment move. This is a company that already values the things I value. They’ve built a strong culture, a strong team, and a strong set of practices. I’m not joining to overhaul anything. I’m joining to help make something great even better.

Why I Joined Test Double
Doc Norton
Collaboration Contracts beta release

Today, I’m excited to announce the beta launch of Collaboration Contracts, a lightweight app designed to help teams—especially distributed ones—quickly define and manage their roles in decisions. Whether you're using it to bring clarity to one-off decisions or baking it into how your team operates every day, the app is built to support alignment, accountability, and smoother collaboration.

Collaboration Contracts beta release
Doc Norton
An Experiment Canvas

The Experiment Canvas is a simple means of planning, tracking, and responding to your experiments.

An Experiment Canvas
Doc Norton
Create simple things in small steps

Simple Things

When I say simple, I don’t necessarily mean easy. And I certainly do not mean crude in form or incomplete. Simple indicates something that does not have superfluous parts or multiple responsibilities, is easy to understand, is as independent from the rest of the solution as possible, and meets a need as is.

Simple may not address all use cases, but it does address some use cases.

Create simple things in small steps

What if no one reads it?

Among the books I am currently making my way through is "Exploring Computer Science with Scheme" by Oliver Grillmeyer. The publish date on this particular book is 1998. No matter how often it happens, I feel a twinge of despair for our profession when I read sound advice from a decade or more ago that has yet to be widely adopted; or worse is still hotly contested.

Grillmeyer contrasts a couple different functions that accomplish the same end. One terse, but obfuscated; One verbose, but transparent. In conclusion, Grillmeyer states, "In a tradeoff between readability and length of code, you should favor readability."

Business Value is not the only reason to adopt Agile

Agile Rob posted a column a few days ago entitled, "If You Don’t Focus on Business Value, Don’t Adopt Agile." He tweeted it out and after reading it, I replied that I did not entirely agree. Rob asked that I post a comment on his blog. The following is an extended/modified version of that reply.

I read two articles today, "Adopting Agile Isn't The Point", by Mike Cottmeyer and "If You Don’t Focus on Business Value, Don’t Adopt Agile.", by Robert Dempsey. Rob's posting is an expression of agreement with Mike's.

Martin Fowler on Technical Debt

Martin Fowler on Technical Debt

Martin Fowler just posted an article on Technical Debt in which he discusses the Technical Debt Metaphor. Fowler argues that the metaphor should (and does) include messy code. He talks about deliberate and inadvertent debt as well as reckless and prudent debt. Prudent and Deliberate is the most desirable. While Reckless and Inadvertent is the least desirable. He published the following quadrant to help explain his concept.

Craftsmanship

I have the profound and intimidating honor of being the fifth person to make note in the Wandering Book. To be honest, I'd hoped to be later in line. I'd hoped I could read numerous entries and ponder all the wisdom before it came my turn to write. As the fifth, I have to admit there is already a great deal of wisdom in the book. The four before me are remarkable people. And those who will follow me are surely remarkable as well.

I'd rather be in last place

I joined the cross country team my freshman year of high school. I knew nothing about the team and little about the sport, but I figured running wasn't too difficult and was certainly less dangerous than football.

It turns out the team was one of the best in the state. They had a legacy of excellence for well over a decade. They consistently won their league, placed in districts and regionals and sent at least individuals, if not the entire team to state.

Messy Code is not Technical Debt

Technical Debt is a common topic these days. How is it incurred? How should we track it? When should we pay it down?

It is a metaphor commonly understood. Our customers get it. While they may not like it, they do understand. Technical Debt is incurred today and needs to be paid down; preferably sooner rather than later what with compound interest and all that.

Keep Retrospectives Fresh

Retrospectives are an important (and frequently poorly done) practice. They provide an opportunity for discussion, learning, and adaptation. Without retrospectives, a team is likely to fall into a soothing rhythm and fail to recognize early the need for change.

But retrospectives themselves can become common and numbing. The same moderator, the same three questions, in the same room, at the same time .... (yawn).

Here are a few tips on keeping your retrospectives fresh.

I disagree with Uncle Bob on this one

I am reading Bob Martin's "Clean Code - A handbook of Agile Software Craftsmanship" again. For the most part, I am really digging it. It reminds me a bit of Steve McConnell's Code Complete. I still have the original version of McConnell's book around here somewhere. But I digress (and show my age).

In Chapter 9, Martin covers unit tests. In listings 9-3 and 9-4, Martin shows the "simplification" of a unit test. Listing 9-3 makes two method calls followed by five assertions. Each assertion checks a specific state. Each state is clearly identified. I do not particularly like the five assertions. But this is not the point that Bob makes. This is not the correction he covers. Instead, he condenses all five assertions into a single assertion by introducing a string of seemingly arbitrary characters.