Another Perspective

Principles vs Methods

A few days ago, I ran across a quote that keys in on a difference I see every day, in nearly every avenue of life


If you learn only methods, you’ll be tied to your methods. But if you learn principles, you can devise your own methods. -Ralph W Emerson


I have, near as I can tell, always been a principle-focused person. I want to know how things work. Knowing how things work makes it much easier to re-combine things, build whatever you want and make better predictions of how things will behave in reality. But, so much of the world around us is focused on methods.

People don’t want to understand how cooking works, they want a recipe: “Just tell me what to set the oven temp to and how long to set the timer.”. They want a step-by-step explanation of how to get rich, not an explanation of what makes a good business.

About the only time I want to be shown the method for doing something is as an example to help me understand the principles behind it. Sometimes, a few examples is one of the best ways to illustrate the principle. But, I often can tell that, as I’m attempting to explain the principle behind something at work, that the listener wants me to quit doing that and just tell them what to do.

The problem with that attitude in software development in particular is that if I can articulate the methods and rules in enough detail for someone to “just follow” them, I can probably write software to “just do it” instead.

During the transition phase of software contracts, as I’m preparing to hand off the code we’ve built as part of the project scope, I get asked for the rules that the maintenance team needs to follow in order for the codebase to stay on track with what we’ve done.

Sadly, the majority of the time, when I start listing the principles we followed in building: (things like separation of concerns, loose coupling, inversion of control, etc.), I see the look if impatience on managers and technologists alike. They want to be given a document with all of the methodical rules they need to follow and the principles don’t give them that because they don’t want to learn/understand the principles.

When I tweeted that quote late last week, quite a few members of the Agile software community re-tweeted it and mention that it really resonated with what they see in how Agile went from manifesto to prescriptive methodology.


Blog Post