Principles vs MethodsOriginally published on 7/5/2015
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.
The original manifesto (http://agilemanifesto.org/), is ALL about principles (http://www.agilemanifesto.org/principles.html). Scrum, the most popular/common "flavor" of Agile (http://scrummethodology.com/) specifically complains about that, right on the front page:
The Agile Manifesto doesn't provide concrete steps. Organizations usually seek more specific methods within the Agile movement.
You're right, the manifesto doesn't provide concrete steps. That's because it's a set of principles. When you take the focus off of the principles and focus on concrete steps, the steps take over. Suddenly, anyone not doing the steps the same way you are is a heretic or "doing it wrong".
In the nearly 15 years since the manifesto was signed by the original group, methodology has completely taken over, to the point that, when I'm in an interview for a new project and they ask if I have any "Agile" experience, they universally are asking whether I have experience in some set of specific methodologies.
The irony is about as huge as irony can get in this particular case because the first line of the manifesto says:
Individuals and interactions over processes and tools
Yet, nearly everyone in the software world now understands "Agile" to mean a set of processes and tools.
There's a similar thing that happened with Domain-Driven Design. The book that defined the topic (http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215) spent a significant portion of the book talking about principles like establishing "ubiquitous language" between everyone involved in a software project. Yet, nearly every conversation I've ever seen on DDD is focused on the small portion at the end of the book that shows an example of how the principles can be implemented.
Related to this whole concept is the idea of asking for "the best" of something. It comes up in the form of "what's the best laptop/smartphone/beer/school?". The thing about that question is that it's absurd to anyone who thinks in principled ways. That's because the principles involved in choosing a proper solution to a problem is rooted in the problem. How do you intend to use a laptop? Why do you want to go to school? Yet, the next time someone around you asks that question, try asking a few clarifying questions that would inform the principles and you'll see immediate impatience on their face. Sometimes, it bubbles over and they say, "Just tell me what the best is, so I can buy it and move on."
Is this some sort of general human bias? Are people who prefer principle-oriented learning and understanding doomed to be a minority by something inherent in how the human brain works? Maybe something related to the 2 systems of the brain (fast and slow)? Or can people be trained to think in principled ways?