The difference between best practices and common sense?

Question

There is a lot of conversation regarding best practices¹ in software development. I've seen at least three major points get a lot of discussion both on SE and elsewhere:

• What qualifies as a best practice, and why?
• Are best practices even worth discussing in the first place, because it's reasonable to assert that no practice is a "best" practice?
• When should you forego a best practice -- or perhaps most best practices -- either because it doesn't seem applicable or because of external constraints (time, money, etc.) that make the trade-off impractical?

Something that seems to come up far less often, but more than never, is a notion of common sense in software development. Recent experience has brought this notion to the front of my mind again.

My initial impression is that it is a different discussion than best practices, but with perhaps some cross-pollination.

When I think of common sense in general, I think of a set of rules that you've either picked up or been taught that give you a baseline to reason and make decisions. Following common sense is a good way to avoid you shooting your entire leg off. But beyond a pretty low baseline, common sense gives way to a need to make educated decisions, and educated decisions can even override common sense when the evidence seems compelling enough. I might be playing a little loose with the definition here, but I think it is close enough to spearhead my example.

When I think of common sense in software development, I think of all of the rules of basic hygiene to prevent a codebase from rapidly decaying into an incomprehensible mess. As examples, things like: not using a single global structure to maintain and communicate state within a non-trivial program; not using variables/method/class names that are just random gibberish; things that probably resemble what we've come to call anti-patterns quite closely. Where applying best practices the practical analogue to learning patterns, applying common sense could be seen as the practical analogue of learning anti-patterns.

With this in mind, I'd like to pose a few questions that seeing the answers of others for might help me reason my way through this.

Do others believe that there is a notion of common sense in software development? Would be interested knowing the reasoning either way.

If so, is it a notion worth discussing? Is it something we should push for as much as we sometimes do with best practices? Is it something worth pushing for even harder?

If the analogy to anti-patterns seems reasonable, the general rule is that anti-patterns are only employed if there is no other way, and even then only under very limited circumstances. How flexible should one be in allowing a codebase to deviate from common sense? It seems unreasonable that the answer is "not at all," because sometimes expediency demands deviations. But, it seems like a different sort of argument than when to employ a "best practice." Maybe it isn't; if you don't think so, I'd like to learn why.

This is far more opened ended and maybe worthy of a follow-on question all its own, what sorts of recommendations would you point at that seem like matters of common sense?

Other thoughts are also welcome.

---

¹Perhaps I would do better to call them "commonly recurring domain patterns", but the name "best practices" is common enough that everyone knows what they are, even if they don't agree that they are. If the "best" part bothers you, just imagine I replaced "best practices" with something less authoritative sounding.

Answer 1

Best practices are practices that have been found to work well in a relatively wide field of circumstances. The problem with them is that A) the expression sometimes is abused for marketing and B) as fixed rules, they are not flexible enough; no set of fixed rules should be followed without thinking about whether they apply to the current situation.

Best practices are great when they come with explanations why they are "best" and in what circumstances they should be used. Then you can reason about when not to use them.

The problem with "common sense" is that it's too flexible - it can be used to justify pretty much anything, and you can't really have a rational discussion when people disagree and both claim their position is "common sense". It's good to have but poor as a guideline for a team to follow.

Answer 2

I think you have it backwards.

When teaching programmers the basics of security, I always teach them to use best practices, and yet when dealing with security experts (or more "security-experienced" programmers) I will never discuss best practices, in fact I will often violate them.

A better definition would be:

"Best Practices" are common sense from experts, as should be applied by non-experts.

That is, you don't get to claim "common sense" until you have enough expertise in the given field to understand the subtle tradeoffs; and when you do, you should no longer be blindly following the cookie-cutter "best practices".

"Best practices" are a temporary placeholder until you have enough experience to use your own "common sense".

Answer 3

Best practices -> "first, you learn the rules". Experience -> "then, you learn when and how to break them".

Willingness to experiment with alternatives (in non-critical code, of course - preferably personal projects and throw-aways) can help build the experience you need to.

Common sense isn't the same as experience, of course, and you don't always need much experience to see the flaw in applying a good technique in the wrong place - but it's very easy to construct false rationalisations for both over-applying and under-applying a technique, and since "common sense" here clearly isn't an innate knowledge of programming, that sense is clearly "common" only within particular groups.

It's very easy to "take sides". Impossible to avoid, in fact - sometimes one side really is right, and the other really is wrong, and it would be irrational to argue for balance. The trouble here is that the real hell isn't so much weighing one best-practice for relevance, but when two conflicting best-practice opinions collide.

Dealing with this is probably much more about people skills than about technical skills. I'm very bad at it :-(

Despite that, it's still important to learn from other peoples experience as well as you're own - ie to find out what the best practices are, why they are used, and what the advantages (and disadvantages) are.

Answer 4

It seems to me that this question is a semantic trickery. If we use these definitions then there is no question:

Best Practice: a field proven way of solving a problem in a given domain (ie. real time best practices are totally foreign to database best practices)

Common Sense: professional experience that serves to warn the programmer of pitfalls to avoid

In the end, a Best Practice is a meta design pattern to solve a particular congruence of problems and is chosen based on real world experiences while Common Sense is a guide to problem solving based on general observation across multiple problem sets.

Answer 5

Common sense = You.CommonSense

Best practices = Sum(Experts.Experience + Experts.CommonSense)

Answer 6

Common sense does not correspond to learning anti patterns, nor is it different from, or in contrast to best practice.

The first problem with common sense is its name - it leads to the conclusion that it is both common and sensible. As commonly used, it is subject to attack on both counts. Using your example:

anti-patterns are only employed if there is no other way, and even then only under very limited circumstances

It is my understanding that this is not the way that anti-patterns arise. It is from an accretion of cultural and social factors; of disregarding best practices and standards over a substantial period; of ignoring the costs in the future to achieve short term benefits - for example to meet a deadline by using a short cut solution that is a maintenance nightmare; etc. No body sets out to adopt an anti-pattern deliberately - they just grow.

Equally, common sense is far too often used to mean "that that is done commonly", and justifying lack of thought, insight, and hard work in resolving what is involved in providing a solution. It is also used as justification for "its the way I do it, so obviously it is common sense" - and as a defense against review and criticism.

As far as best practices are concerned @Michael's first two paragraphs are an excellent summary of what best practice should be - a resource to assist everybody to improve what they do. It also provides transparency of decisions (design decisions particularly) and the capability to learn from others. The downside of best practice is when it generates a checklist culture - "I've ticked all the boxes, so what I've done must be alright" - without applying thought, care and attention to the nature of the applicability of the checklist.

Answer 7

Interesting timing. Last week this article was published discussing why common sense is not necessarily ideal in all situations.

Common sense is exquisitely adapted to handling the kind of complexity that arises in everyday situations...And because it works so well in these situations, we're inclined to trust it in all situations

(my words in bold)

Basically - humans aren't good at using common sense in areas such as this where we haven't developed an ingrained system, so we should ALWAYS use a documented set of standards and not rely on our own common sense!

Answer 8

This is a slippery slope argument that often devolves into a religious war.

Almost any best practice can be countered with a valid case for doing the opposite.

Some best practices are more "best" than others. Global state variables are almost always better done a different way and GOTO is usually a bad idea, but when you get into the pattern/anti-pattern or direct data/abstracted data arguments it gets a little less clear. Even more so when you start talking about development methodologies and practices.

In some situations common sense and best practices are even in opposition to each other.

There is no governing body of best practices and no single group even if it did exist could define every possible "best" for every possible situation. Many things labeled as best practices are just bad marketing trying to sell uninformed individuals tools or training.

Even when your entire team agrees that something is best it is not always possible to implement it that way for various constraining factors.

IMHO you have to use best practice as a guide as to what to consider more carefully in your design. You may have a valid reason for deviating, but you probably need to make certain that everyone else on the team agrees before you go and build something odd.

Some of the arguments about best practices after that point pretty much boil down to not building something that the next developer that has to work on it will hate. Everyone hates code that isn't their style, and everyone blames everything on anyone that leaves, so either you are going to explain it to the next dev after they grumble about something, or you aren't going to be there and get talked bad of regardless of how you code it. This makes that concern mostly irrelevant.

Answer 9

Common sense does not always yield the best results. Best practices, however, have been tried. This makes best practices a more reliable source of information.

Answer 10

The best practices aren't best, and common sense isn't common. ;-)

For either best practices or common sense, I like to think of them as patterns; Remember the definition of a pattern: A solution in a context resolving forces into a resulting context.

For anything you want to do, you should know the context that it applies to, the forces it resolves, and the resulting context that it creates. Then, decide on your team what the patterns you are going to generally use are. (This can be formal or informal, but either way, it's much larger than just the Gang of Four book. This includes language idioms and local helper libraries, not just published patterns.)

If you feel, based on your experience, that in a certain circumstance, it would be better not to use a given pattern, but to do something else, let people know. Probably the context or forces are different here (or perhaps the resulting context would be unwanted.) I don't care if it's a meeting, a code comment or what, but if you make it clear that you have broken the pattern on purpose, you'll be miles ahead.

Answer 11

Everything including "Best Practices and Standards" can be a bad thing when applied too much or without "Common Sense". Blindly applying things all the time and using the argument that it is a Best Practice or Standard as the argument can be just as detrimental as never using them at all. It is incumbent on developers to employ common sense and weigh the benefits of doing something one way or another. To me a good rule of thumb is to ask my self is what I am about to do or what I have done going to affect the Scalability or performance of the application, and then after that I ask myself is what I am about to do or have done going to make the person behind me not be able to understand or support the product if I am not there.

Answer 12

Best practice is what they teach you at school, Common sense is what the boss wants form you. The former creates software that meets certain standards of elegance, style and such like. The latter pays the bills/makes the money so you get paid each week.

One is art, the other business, too many of us forget it.

Answer 13

To exaggerate a little: The difference is Common Sense is Prejudice, Best Practice is (should be) Science

In my experience, 'Common Sense' is used when one does not want to provide proof or at least arguments for a way of doing things. That does not mean the way is neccessarily wrong, but it doesnt mean it is good either.

Among the things i encountered, that were rationalized as beeing common sense are these gems.

• the HTTP-Method is largely irrelevant, use GET when you transmit little data, use POST when transmitting more (i.e., to much for the URL)
• functions should not be too small, because it's hard to remember what they do. one big function is preferable to 5 smaller ones, because you can read it as one
• the database and the webserver MUST run on the same machine, or else the webservice will get to slow. The only way to scale is to speed up the code by hacks and by forgoing abstraction, so that the power of one machine suffices.

The funny thing about 'Common Sense' is, that it is not that common: pick two teams and let them state what they thing is 'common sense', and enjoy the religious wars.

On the other hand, as 'Best Practice' i would consider ways of doing things, that have a little more 'peer review'. To consider something a 'best practice', i would expect it to be formulated clearly enough so that it can be presented as a concept ('structured programming' is best practice, 'gotos are confusing, avoid them' is common sense), and applied more than once, with good results.