Ted Neward is the Principal at Neward & Associates, a developer services company. He consults, mentors, writes and speaks worldwide on a variety of subjects, including Java, .NET, XML services, programming languages, and virtual machine/execution engine environments. He resides in the Pacific Northwest. Ted is a DZone MVB and is not an employee of DZone and has posted 50 posts at DZone. You can read more from them at their website. View Full User Profile

Death to Best Practices

08.10.2010
| 32022 views |
  • submit to reddit

Can we please put the whole term “Best Practices” to rest now? Apparently, according to this link (forwarded to me by John Dietz, thanks!), the very place where it originated (or was best popularized, depending on your interpretation of history) has now seen the whole concept basically debunked:

For example, Jim Collins’ blockbuster business book Good to Great, published in 2001, featured 11 supposedly great companies. All of them did extraordinarily well on the stock market for 10-20 years. But by 2008, when Steven Levitt posted Good to Great to Below Average on Freakonomics, two of them had died.
(Read more: http://timberry.bplans.com/2010/07/the-sad-truth-about-best-practices.html#ixzz0wBOxDrkh)


The point is, best practices just don’t exist. They are an attempt to take a solution to a problem out of the context and apply them across the entire spectrum, and that essentially invalidates the entire thing. A solution is only useful when considered in context.

Don’t believe me? Consider this challenge: when is it not a best practice to breathe? When you’re under water, of course.

(Unless you’re a fish. Or a frog. Or maybe a prince turned into a frog.)

Point is… context matters, folks.

Blind application of best practices don’t work, as Tim Berry’s article quotes from Jim Collins’ book (my emphasis):

Nine of the eleven companies remain more or less intact. Of these, Nucor is the only one that has dramatically outperformed the stock market since the book came out. Abbott Labs and Wells Fargo have done okay. Overall, a portfolio of the “good to great” companies looks like it would have underperformed the S&P 500.


Still think that the “best practices” idea might work? Prove it to yourself: do a detailed study of CEO performance across any given CEO’s career and across a variety of different companies who changed CEOs. In short windows, yes, you can find scenarios where a CEO had a stellar performance with a particular company for a particular period of time. But when you pan back and look across the CEO’s entire career (during which he/she practiced the same “best practices” at different firms), almost none of them have repeatable successes at a variety of different firms in any consistent manner (despite the millions handed to them).

In other words, for a good many of them, their success was nothing but blind luck. A monkey could have done just as well. The “superstar CEO” is generally a product of the five or so years in which his one firm was wildly successful.  Attempts to repeat the success at other firms (that is, in a different context) typically have failed or generated mediocre results. (Anybody know what Lee Iacocca is up to these days, he of “I will rescue Chrysler” fame? Come to think of it, can anybody name any of the 70’s or 80’s “superstar CEOs” that is still wildly successful today? Just one?)

How did this “best practices” thing get to be such a common meme? Because “best practices” mean, essentially, that the questioner doesn’t want to have to think. And it’s a seductive premise—if I just push the right buttons, type the right keywords, call the right methods and/or use the right classes, I can get something that “just works” without having to think about all those nasty little details that seem to trip people up: performance, scalability, security, blah blah blah.

Here’s the dirty little secret of our industry: Software development is hard.

Computer science is about tradeoffs and hard choices. Optimizing the code or design or architecture one way means taking hits another way. Trading static typing for dynamic typing means losing a set of already-written unit tests in exchange for a degree of flexibility in certain parts of the design. Using inheritance instead of parametric polymorphism offers some benefits but also adds some restrictions, and vice versa. Choosing an agile approach gains you greater feedback and closer connection to your customer (which typically means you’re closer to budget and critical features being completed on time), but requires more work and expertise to pull it off over other, more waterfall-ish, processes. And so on, and so on, and so on.

Tim says this well:

Don’t ever just blindly follow. You always think about it, consider the options, how it might be different in your case, and then, if it still sounds good, try it. Carefully.

If I ever give you any advice, I want you to please never take it without thinking first, analyzing, and deciding for yourself whether or not, and how, and to what extent what I say fits your situation.

(Read more: http://timberry.bplans.com/2010/07/the-sad-truth-about-best-practices.html#ixzz0wBQU3yCB)


But it’s not just the questioners’ fault: speakers, in their zeal to prove that they were smarter than everybody else, bought into the idea, too, because if I’m the one holding the “best practices”, then clearly I’m the one you want to come to with the development or consulting work. After all, who better to hire than the guy/gal with all the answers? In essence, we fed their addiction by tossing off “best practices” in pithy one-line answers (like “every class a service”) that turned out to be utter B/S pronounced by people who had, in some cases, never actually put that practice into practice for anything other than a demo or an example.

It’s time to say “no” to “best practices”.

Speakers: The next time somebody asks you for the “best practices” on a technology, respond with “The best practice you could possibly employ is to hire me.” That, or else with “There are no such thing. You cannot answer a question about a problem outside of its context.”

Attendees: The next time a speaker starts talking about “best practices”, walk out, because clearly the speaker is trying to feed you easy answers when in fact there are only hard choices.

It’s time for our industry to break the habit of taking hits off the crack best practices pipe, and start facing the fact that software development is hard.

References
Published at DZone with permission of Ted Neward, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

David Witherspoon replied on Tue, 2010/08/10 - 9:54am

I disagree...you are throwing out the baby with the bathwater.  Best practices aren't bad, but the blind application of best practices without considering context is bad.

Development and sharing of best practices is human nature. Go back to cave-man days...they had plenty of best practices. Hunt down a buffalo, cut away the meat and cure it to save for winter, be careful to cut the hide and scrape it clean, save that to make a coat, clean the bones to make various tools, save the fat for cooking, etc. 

Of course there's context with that. Don't hunt the buffalo in a tornado. Don't save the meat if it's been sitting out in sun for a week. And so on.  "Best practices" goes by another name...wisdom.

Hunting buffalos is hard...so the common wisdom passed down helps to provide general guidance. When the game changes, most of that common wisdom is no longer relevant.  But new wisdom will be developed and shared. It's how we survive.

Andrew Gilmartin replied on Tue, 2010/08/10 - 10:38am

I also disagree. You are mixing macro and micro problems and their solutions. Macro problems are often wicked problems -- problems that do not have a solution in their own definition. There are no best practices -- that is prescriptive solutions -- for these. Micro problems, on the other hand are tractable and lend themselves to prescriptive solutions. For each kind of these problems there are one or more best practices that can be integrated into the solution. Best practices need to be fitted. If they didn't they would be called Best Parts.

Josh Berry replied on Tue, 2010/08/10 - 10:43am

You attack the piece with vague instructions.  I think that is the problem with best practices in our industry.  They are great as ideas, but we try to share them as implementations.  (Something that is rather unique to our industry.)

Marcel Offermans replied on Tue, 2010/08/10 - 11:13am

I agree with Ted about not adopting "best practices" and a very nice talk on this subject I remember is Dan North's talk at Øredev called "No best practices?" which can be seen (for example) here.

Oliver Searle-Barnes replied on Tue, 2010/08/10 - 4:15pm

Couldn't agree more. The focus on best practices has been very damaging. It leads developers to think that there are cookie cutter solutions to development problems. In reality there are always many different factors at play, often conflicting with each other. By understanding the relationships between these different factors we can resolve them into solutions.

A great example is the open/closed principle which mandates that code should be open for extension and closed for modification. In a pre TDD context this makes sense. When every line of your code is tested the risk of change is already taken care of. In this case the extra abstraction that the open/closed principle might mandate would be an unnecessary expense.

TDD is actually fantastic for breaking down the mindless application of "best practice". Because you start with specific examples and generalise through refactoring you are forced to justify any abstractions that you introduce.

Another classic example is the implementation of Service/ServiceImpl/Dao/DaoImpl where a single Service class is often perfectly sufficient. How often have you seen identical Service and Dao interfaces and a Service implementation that simply delegates to the Dao?

Mcgeorge Bundy replied on Tue, 2010/08/10 - 5:52pm

TDD isn't a best practice? CI? What are they, "fantastic practices"? The arguments given hardly support the premise.

I disagree with Ted. There aren't only hard choices. There are easy choices. TDD, CI.

One good argument supporting Ted's point was recently made by Jeff Bezos. When asked about the competition between the Kindle and the iPad, Bezos said that industries succeed, not just companies and that customers, not companies, decide what products succeed in the marketplace. I don't think anyone thinks that any best practice of the IT department is an element in that equation.

I saw Ted give a presentation on F# and the only example that was more involved than a println he couldn't get to run. A best practice for Ted might be to get his presentation's examples to work if he is going to also promote his upcoming book.

Stephane Vaucher replied on Tue, 2010/08/10 - 8:34pm

I believe he means that it is difficult to generalise successful practices into universal "best" practices. The article is a bit long for the message, but I do not disagree with the statement. I worked on metric programs for software QA, and context is key.

@Mcgeorge Bundy - "TDD isn't a best practice?"
As Ted said, it depends on the context. Try working in the aerospace industry.

Cosmin Mutu replied on Wed, 2010/08/11 - 12:41am

Come on, best practices is all about "NOT REINVENTING THE WHEEL". If somebody found a solution for a problem, which belongs to a particular group (class) of problems, then that solution can be easily used for any other problem in that group.

You, instead, are stating that the definition of BEST PRACTICES is that if you found a solution for a problem, then that solution should work for all the problems in the world.

Now ain`t that cute? BUT IT`S WRONG! :)

Cosmin Mutu replied on Wed, 2010/08/11 - 12:54am in response to: Stephane Vaucher

TDD is for programming like CROP ROTATION is for farming. Of course context matters, TDD might not work for all the industries (programming) and CROP ROTATION might not work for every type of vegetable / cereal, but it works for most of them, which makes it a BEST PRACTICE! :)

Alex(JAlexoid) ... replied on Wed, 2010/08/11 - 5:16am in response to: Mcgeorge Bundy

TDD is not always the best option. SAme goes for CI. It all depends on context.

David DeCesare replied on Wed, 2010/08/11 - 7:41am

Everyone gets their head wrapped around the word "best". They aren't "best" practices, they are practices. Just like we don't have "best" design patterns...we have design patterns. What system designers (not just software) have to contend with is which practice works best for their given situation as Ted outlined.

The term "best" practices comes from the notion that there is some "average" or "normal" project out there which just isn't the case. If you are working on an average project, you are wasting your time developing it since you could probably just buy a solution off the shelf (maybe even the BEST off the shelf solution).

Lance Smith replied on Wed, 2010/08/11 - 10:27am

 

So what else is New ?   In the 1960's Oreration Research (OR) was hailed as the solution to all of mankinds problems and every company of any size was clammering for OR specialists to save them from themselves.  It was soon discovered that in the "context" in which the OR was developed its was outstanding, but when applied to other applications across the board it fell flat on its face.

So the cry of "Best Practices" is the same old song with a different beat since you've been gone.  In the problem context in which the practice was developed to it works well, but before declaring the end to all of mankinds problems care should be taken before applying across the board.

It should also be noted that once a best practice is implemented, bureaucracies tend to cast them in concrete and the practice obtains the staus of  "imutable corporate law".  When the problem context in which the practice was developed to solve changes, corporate forces are slow to non-existent to recognize this and change practices accordingly.

 

Mcgeorge Bundy replied on Wed, 2010/08/11 - 1:09pm in response to: Stephane Vaucher

Stephane, If TDD isn't warranted, then it won't be a hard choice to discard it, will it? Its still an easy choice.

Allan Bond replied on Wed, 2010/08/11 - 4:40pm

I had a professor who used the term 'good practices' instead of 'best practices'. I think that makes a big difference because 'best' connotes a practice that is somehow final or beyond dispute. I always feel uncomfortable when people talk about 'best practices'...seems a little presumptuous and I think it sometimes causes people to shut down their thought processes on whether they should even apply a practice to their specific situation.

Using the term 'good practices' leaves the door open for improvement and tweaking of existing practices.

Stjohn Kettle replied on Wed, 2010/08/11 - 6:03pm

I too think that Best Practice is a term that causes more trouble than it is worth. And I share Allan's view that 'good practice' would be preferable for the reasons he suggests -- it allows room for debate, for asking the question that Ted raises: is it good practice for us in our context? I don't mind coming someone coming up to me and saying - have you thought of doing it like this? I've heard it's good practice. I object to being told -- as one so often is -- do it like this because it is best practice. It is also strange that it is always used to get us to do something else - I have never been told -- 'well done, you're doing best practice' (perhaps I really am hopeless . . . ?). It is as though those who have power keep us in a state of constant insecurity with this term.

Bob Zormeir replied on Thu, 2010/08/12 - 10:34am

I'm sick to death of "best practices" that are just an automated way of Begging the Question.

Shoaib Abdullah replied on Mon, 2010/12/27 - 2:57am

Sharing and development of best practices is human nature. Go back to cave-man days...they had plenty of best practices. Hunt down a buffalo, cut away the meat and home decorating theme cure it to save for winter, be careful to cut the hide and scrape it clean, save that to make a coat, clean the bones to make money by pay per service various tools, save the fat for cooking, etc.

Caoimhin Bach replied on Wed, 2013/01/23 - 1:45pm

I think this article is too simplistic. First of all, the term "Best Practices" is way over used. I totally agree with that. Saying something is a best practice, implies it is the only way it can be done, which Ted rightly points out isn't the case. 

Additionally, design patterns have been overloaded into the term best practices. This is where the article should have gone. Saying using Dependency Injection, or an Abstract Factory is a best practice is clearly wrong. It implies that it is the "best" (read only) way to go, and that is definitely not the case. Ted correctly points out that software development is hard - which, unless you're writing a Hello World demo is absolutely true. But even a "Hello World" piece of code could be written in several, all probably correct, ways.

However, there are good practices. As pointed out above, TDD and CI are two of them. It doesn't matter whether you're using agile or waterfall, these are very good practices. However, there are many ways of doing TDD, and how one team does it, may not work well in another environment.

I think Best Practices is a term that should die. Good Practices, as Allen Bond's professor used, are more correct. 

This goes a long way as to other terms used in the industry. What developers are doing is not "Science," nor in many cases is it "Engineering." Hardly any team follows engineering or science practices. Most developers should aspire to be craftsmen, and should have in their toolbox a whole bunch of "Good Practices" many or which are alternatives to one-another as well as complement one another.

So while I agree that the term "Best Practices" should die, I do not believe that all the actions that have previously been defined with that term should go the same route. They should be included in the armory of every development team and used where necessary until they are proven "Bad Practices."

I do not use the Best Practices term. I've been saying Good Practices for a while, but more often I just say do what we think is best for the project. That implies that a certain practice is best for a particular project task, which may actually be the case, but it doesn't make it a best practice, which would imply it's the best solution in every situation.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.