Software Best Practices

Beyond the fact that these two words are becoming so ubiquitous that they are starting to lose meaning, I just don't like this phrase. "Why, Kevin", you may ask, "whatever is wrong with wanting to do the best you can".

Let me say that I have no particular qualms with any of the information presented on this site, or with Construx in general. In fact, I bow in the direction of Steve McConnell three times daily. It's the way that people are using the term to quash dissent, reduce criticism and mainly ram things down people's throats.

The IT manager at my last place of employment had set up the network to change passwords every 30 days. His response every single time the multitudes cried out in pain was to hold up a sheet of "best practices". Yahhh!

 
How can you question something if it is "the best"? What incentives do we have to improve if what we are doing is "the best". I don't have a solution here, just taking a minute to vent.

Okay, I'm better now.

Thanks,

Kevin

 

Hi Kevin,

Secretly, I agree with you. "Best practices" doesn't really mean much by itself. It is also becoming a buzz word (or buzz phrase if you will). The working definition I use and what I promote are practices that have shown themselves to produce positive results in multiple situations. "Better practices" or "Positive practices" might be better but the name sure doesn't promote as much confidence!

You are also right that doing something just because somebody said it was a "best practice" is pretty darn foolish. The only practice that can be "best" is one that statistically stands out by trying them and comparing results; a difficult thing to accomplish in an environment where we don't build thousands of the same thing.

But hey, why stop at banning "best practices"? Shouldn't "agile", "refactor", and the up and coming "lean" also be on the list?

Earl Beede:

Hi Kevin,

Secretly, I agree with you. "Best practices" doesn't really mean much by itself. It is also becoming a buzz word (or buzz phrase if you will). The working definition I use and what I promote are practices that have shown themselves to produce positive results in multiple situations. "Better practices" or "Positive practices" might be better but the name sure doesn't promote as much confidence!

You are also right that doing something just because somebody said it was a "best practice" is pretty darn foolish. The only practice that can be "best" is one that statistically stands out by trying them and comparing results; a difficult thing to accomplish in an environment where we don't build thousands of the same thing.

But hey, why stop at banning "best practices"? Shouldn't "agile", "refactor", and the up and coming "lean" also be on the list?

Well, theoretically there is always room to be more agile, refactor is a verb, so there is practical aspect to that. As for lean, I suppose you could go even further and have anorexic development.

I suppose my point is that while those other words make claims about the kind of practice that it is, they do not claim to be the ultimate practice. Which isn't to say that the practitioners themselves don't make those claims :)

I tend to assume that among the engineering community, the terms are viewed as you described. What always scares me is when one of the pointy-headed gets a white paper and an idea.

Like I said, I need to vent.
 

 Kevin's objection to the absoluteness of "best" practices strikes a chord with me.  Branding something as "best practice" kinda implies that doing anything else is at best... well... second best.  And none of us are inspired by striving for "second best".

It got me to thinking... are best practices a default?  That is, if you don't have any other information then should you default to the "best practices"?

Kinda like shoes.  I think my New Balance running shoes are "best shoes".  If I know nothing about where I'll be going or what I'll be doing they are a good all around shoe.  I'm unlikely to get myself in serious trouble if I wear them.  But if I have more info about what I'm likely to be doing (e.g. hiking a glacier or going to a black tie ball) I may choose other shoes.  And the shoes that are "best shoes" for me are almost certain to not be "best shoes" for someone else.  In fact, given different circumstances, different people probably have different "best shoes" that are radically different from mine.

I think best practices are ones that you can fall back on and feel fairly safe.  They are unlikely to get you in trouble.  Now you are almost certain to be able to build a set of practices that are better for your situation than the generic "best practices" but you want to be a little careful about that.

One nice thing about best practices is that they form a shared set of principles that (whether you agree with them or not) form a basis for further discussion.  Until you are familiar with those best practices it is very hard to have an in-depth conversation with someone in that field since you are almost literally not speaking the same language.  Sharing the knowledge of what current "best practices" are in your field is important even if you don't necessarily practice those particular "bests".

Kevin asked, "How can you question something if it is 'the best'?"

I think the trick is to ask, "the best for what?"  That turns it into a discussion of what results you want to achieve by employing the practice.  Now that I write it, when I think of "best practice" I almost translate it as "good starting point".

What do you think?

 Bruce,

I agree exactly with your description of how these practices should be used. It seems we have a classic Reality v. Marketing bit of cognitive dissonance. As you describe it "Best Practices" translates to something like "Foundational Knowledge". Which is closer to the truth but further from the ability to convince (or sell, whichever you prefer).

So, here's my challenge, one for which I don't have an answer:

Is there a term or phrase that can capture both the excellence and adaptability that we want?
 

Kevin:

Is there a term or phrase that can capture both the excellence and adaptability that we want?

The only term that comes to my mind is "proven practices." But that still falls short. It begs the question of proven under what circumstances?

At Construx, we often talk about best practices -- but when I'm leading seminars, I find myself talking more about building your own toolbox of practices.  That is the best practices are the ones that you have adapted for your use.

When talking about this, I often use the Goldilocks and the Three Bears metaphor -- She had to try three beds before she found one just right. Likewise, you will have to experiment and adapt your practices until you find the "best practice."  Also keep in mind that like Goldilocks, you will grow. So the bed that is just right today, will not be the same one that is just right in the future. 

 I started to write about this, got wordy and sidetracked, and realized I was going to hijack the thread. :)

 So I blogged it, instead: http://eddiesguy.blogspot.com/2007/06/methodology-fundamentalism.html

 I'd love it if we came up with a different term; it *has* become a buzz word. But it wouldn't be long after we came up with a new term before it, too, became a buzz word.
 

Read your blog post essentialgeek, nice.

I agree with what you wrote but the delimma is there. What do you call the practices that have shown themselves to be a good idea at other places and should at least be considered? It seems a lot like design in that you need to weigh mulitple factors to choose a practice but, at the same time, have a whole bunch of practices/patterns/approaches to choose from!

Earl Beede:

Read your blog post essentialgeek, nice.

I agree with what you wrote but the delimma is there. What do you call the practices that have shown themselves to be a good idea at other places and should at least be considered? It seems a lot like design in that you need to weigh mulitple factors to choose a practice but, at the same time, have a whole bunch of practices/patterns/approaches to choose from!

Well, at the risk of getting wordy (as I writer I tend to do that), I'd suggest a change of metaphors.

I like to think of them as a palette. Artists choose colors from a palette. Similarly, we should be choosing the practices that best suit our needs from a palette of practices.

Further, I'd suggest a change in terminology to something like proven methods. Best practices, while catchy and highly marketable, is a bit vague. If, on the other hand, we're working with a palette of proven methods, that tells me that I'm supposed to choose one or more proven methods from a palette of them, and mix and match them to suit my business's needs.

The way that this whole thing is running now, you kind of get the impression that it's an all or nothing deal.

Well, then this site can be the Software Preferred Practices Palette! You're right, not as nice sounding but it does have the alliteration thing going for it.

Earl Beede:

Well, then this site can be the Software Preferred Practices Palette! You're right, not as nice sounding but it does have the alliteration thing going for it.

 Well, that's positively dreadful. I despise alliteration in all its forms. (Apologies to Mr. Tolkien.)

Well, back to the drawing board, then. :)
 

Well, we are sort of where I thought we would be. <sigh> That is, more or less stuck with "Best Practices". </sigh>

The comment that any replacement for the buzzword would just become the next buzzword is completely accurate. In the end we are left with what we always have: the ability to explain our reasoning behind our practices, what they deliver, and what they don't.

As I said, mostly just a rant on my part anyway.

Well, how about 'Good practices'?

It indicates that you are safe to use them, but also that it still has room for improvement.

Just don't know how to communicate that each improvement is very probably site/project/company specific.

Best practices to me means

Practices that we want to improve but haven't yet found a replacement for or better way of doing

but that is a bit of a mouthful! If anything we should probably call them "Current practice". E.g. Current practice for Software Design at company X is Y but Company Z do it using Á

But wouldn't you agree that there is a subset of all possible practices that have shown themselves over time and multiple areas to be better than other practices? For example, while starting coding immediately can work now and then, doing some amount of planning (big plans, planning games, etc.) is a safer bet? What do you call that subset?

Maybe we need practice safe sets.

Earl Beede:

But wouldn't you agree that there is a subset of all possible practices that have shown themselves over time and multiple areas to be better than other practices? For example, while starting coding immediately can work now and then, doing some amount of planning (big plans, planning games, etc.) is a safer bet? What do you call that subset?

Maybe we need practice safe sets.

"Now and Then" seems to be the key words in this. It all depends on context. Which leads me to: "Contextual Practices". Do the best thing for the job at hand. When you know the job at hand, the best practices follow. 

"Maybe we need practice safe sets."

I saw what you did there. *snicker*

We use 'best practice' to represent the essence of what works in and out of our company.  It's the 'kernel' we adapt from at the project level but defined top-down and approved by middle managers (supervisors up to the design engineering head).  Adaptations that seem to deviate from 'best practice' need to be justified, officially waived and planned for. 

Example:  Some projects have a policy of 100% review coverage, i.e., review all documents and all their pages.  Some projects only review new documents and new or modified contents in existing documents.  Which one is considered 'best practice?'  In our company's 'kernel', we don't say.  In it, we say that projects should decide what to review as long as they follow the prescribed peer review processes (of which there are three).

Most of you already said it.  Best practice is only a snapshot of what's working now.  The best practice today may not be the best practice tomorrow.

Unfortunately, software best practices are not silver bullets.  A company with best practices can still be shot down by people problems.  This actually goes against what H. James Harrington, author of Total Improvement Management, says in that book -- winners consider the process as the cause of problems.  Personally, I disagree but this is another discussion for another thread :)

Earl Beede:

But wouldn't you agree that there is a subset of all possible practices that have shown themselves over time and multiple areas to be better than other practices? For example, while starting coding immediately can work now and then, doing some amount of planning (big plans, planning games, etc.) is a safer bet? What do you call that subset?

Maybe we need practice safe sets.

Lol

Yes so perhaps as well as Current Practices we need Current Rejected Awful Practices? Those practices that  we end up doing but produce nothing but rubbish output...