Why Principles Matter in Software Development

Principles? We don't need no stinkin' Principles!
Over the years that I have been working with software I have noticed a couple of things about principles. One of the first things that I noticed is that when you mention principles, people tend to get either confused or up-tight. I think this is mostly because they think that principles are things that are quite personal. I don't want to talk about my principles. I want to talk a bit about using principles when creating software.

Principles are not Rules
First off, principles are not rules. Principles are also not policies. Principles are the thing that we use for creating useful, sensible policies and rules. Rules without a principle behind them are just senseless bureaucracy. In a way, principles are rules about how to make decisions (and rules). Joel Spolsky talks about principles quite a bit. For example:

When you design user interfaces, it's a good idea to keep two principles in mind:

1. Users don't have the manual, and if they did, they wouldn't read it.
2. In fact, users can't read anything, and if they could, they wouldn't want to.

These are not, strictly speaking, facts, but you should act as if they are facts, for it will make your program easier and friendlier.
—Joel on Software, User Interface Design for Programmers

Joel is saying something really smart here. You can take these principles and apply them to any user interface you are designing. You don't have to think about the gritty little details of every special case of users and software working in combination. And the kicker? If you're working with other people (like project managers or testers) and you all agree that these principles are ones you will pay heed to, then you will be more efficient.

Did you bring enough to share?
Principles are incredibly powerful when they are shared. If you share a principle with someone (like whether or not recursion is a good idea) then each of you can make important decisions without having to talk to each other about everything. The more people that share the principle, the more powerful the principle gets. Just think, if ten people share a set of principles and one of them needs to make a decision then, rather than calling a meeting and hashing out the details and all possible outcomes, that person just consults the principles and makes a decision based on them. A principled decision.

That's one reason why start-ups (good ones anyway) tend to be so amazingly productive; all the members share the same principles. Each individual can make independent decisions that are the same in principle as the decisions that the group would make as a whole.

This is also a reason why long established and large companies tend to be so amazingly bureaucratic (bad ones anyway). The principles behind many of their rules and processes have either changed or never been explained to the people who have to follow them. So the rules have lived on, orphaned from the principles that spawned them.

Dave Thomas (of Pragmatic Programmers and Rails fame) wrote:

Andy Hunt and I once wrote a debit card transaction switch. A major requirement was that the user of a debit card shouldn't have the same transaction applied to their account twice. In other words, no matter what sort of failure mode might happen, the error should be on the side of not processing a transaction rather than processing a duplicate transaction.

So, we wrote it on our shared whiteboard in big letters: Err in favor of users.

It joined about half-a-dozen other maxims. Jointly, these guided all those tricky decisions you make while building something complex. Together, these laws gave our application strong internal coherence and great external consistency.

—Dave Thomas, The Pragmatic Programmers

He's talking about shared principles here. These "maxims" were the principles that drove their development philosophy. A foudation that they built their software upon. And if the users agreed with the principles, then they were that much more likely to love the software.

You will certainly want to share your principles with newly hired employees too. A large part of getting new employees onboard and productive is infecting them with the principles of your company. This is critical if you want them to make decisions on their own. If you want to see this in action then look at companies like Nordstrom. In Good to Great, author Jim Collins lays out how Nordstrom goes about this. It is a very interesting read.

So, what about software?
I've been involved in a couple of major re-writes of code. Why am I bringing up re-writes? Well, the thing about a re-write is that the intended function of the code is often very similar. The reason that the code is being re-written is often that it did not perform as intended in some way. In fact, the functional specification may not have changed one bit.

Now this is interesting because if the spec didn't change, and the principles of the members of the development team didn't change, then the decisions they make will not change significantly. One person will decide that things work better if you follow design principle x (all "Next" buttons go on the bottom of the page). Another decides to follow conflicting design principle y (all "Next" buttons go on the toolbar in the footer). In the end the project suffers from the same overall "badness" that probably caused the re-write in the first place.

Every major re-write that I've ever been a part of has failed to produce a good outcome when the same people worked on the new version and did not have a "Come to Jesus" meeting (or meetings) where they reach agreement in principle on how they would make decisions.

Every time there has been agreement in principle, the outcome has been better and reach much more quickly.

I've covered some of the principles that I use in making software development decisions here.