It never ceases to amaze me how many things I’ve read, learned, and internalized that can be boiled down to simple, related concepts.

I started writing this blog post with the intent of talking about principles vs. rules. That comes up a lot when someone is asking me about the “proper” way to write a user story. I often simply tell them that user stories are just a reminder to have a conversation and that one of the agile principles is “…interactions over processes and tools.”

But that got me thinking of a conversation with somone that was unhappy about things in our coding standards. He’d heard a podcast give the opposite advice and, when he asked someone on the team about it, they responded “that’s been the rule since I started here.” Throughout the conversations that followed, I realized that neither of them knew the reason we implemented the rule: we felt it was better to have a standard than not, but didn’t really have an opinion on the details, so we just picked one from the internet. It meant the rule was open to change if someone made a compelling case for it.

All of that got me thinking about the emphasis we put on WHY comments (compared to WHAT), the phrase “strong opinions, held weakly” and the client request vs. implementation details.

Reflecting on all that, I’d put all of this under the umbrella of “asking why.” It is important to understand why you’re doing something, such as following a rule, building a feature, or trialing a new piece of software. That will give you the ability to ask smart questions, challenge assumptions, and ultimately proceed in the best way.