Best Practices are Subjective and Fleeting


I've long had an aversion to the phrase "Best Practices". As I started out writing software, I looked to my mentors and industry leaders to inform my decisions about how things should be done. If they shared their "Best Practices", I took them to heart. I wanted to be the best coder I could possibly be.

Hungarian Notation is a Best Practice?


For years, I used Hungarian Notation. This was a practice established in the late 70s and later promoted by the likes of Steve McConnell in Code Complete, first published in 1993. When writing in FoxPro or versions of BASIC, this proved helpful. The languages had limited concepts of type and the mnemonic pre-cursors on variables helped me be a responsible citizen and steward of the code. I doggedly followed this "Best Practice" and encouraged my co-workers to do the same.

I then started writing more C/C++ code. I continued the practice, knowing it was part of what made me a better developer. But I lost sight of why this practice was previously of value to me. So I was not only explicitly declaring a type, but I was then naming the variable to indicate type, while working in an environment where the compiler enforced type. The naming convention didn't serve its intended purpose in this context, and yet I continued the practice for years.

In Clean Code, Uncle Bob tells us not to use Hungarian Notation, but Joel Spolsky recommends it. 20+ years later and the debate over whether or not this is "Best Practice" endures.

Look deeper at the debate. Consider what Steve, Bob, and Joel each say. They provide a set of objectives in a given context and then show how what they've chosen to do is optimal for them in that context. That doesn't indicate a universal best. It's contextual and it's predominantly subjective.

Uncle Bob tells us Hungarian Notation makes code harder to read. Joel tells us it makes code easier to read. These are subjective evaluations. I doubt either of them has run a comprehensive double-blind study an a large population to ascertain if Hungarian Notation is statistically more or less readable. My apologies to them if they have.

Some Other Best Practices


This is but one simple example. There are hundreds of examples in our field. Your burn down versus my Gantt Chart. My backlog versus your project plan. Inheritance, Composition; TDD, BDD; Scrum, Lean; Comments, No-Comments; Tabs, Spaces; camelCase, snake_case; OO, Functional...

So...
Which of them is wrong?
Are any of them right?
Which pundit's pontification of programming proficiency is predominantly preferred?

These are useless questions.

Find Your Own Best Practices


Here is a useful question, "What could we change for the better?"

I'm not saying we change all the things. And certainly not all at once. But I am saying that every team should be looking at their approach, questioning their perceptions, and putting their "best practices" to the test. And if you decide to implement something because it is a "Best Practice" treat it no differently than some "wild idea" you came up with in a retrospective.

Measure what you're optimizing for. Measure what else is important and might be adversely impacted. Make a change and see what happens. Adjust, adapt, learn, grow.

1 comment:

  1. Here's the comment to this post that I entered in the LinkedIn Software Craftsmanship Group discussion thread. Thought it would be good to share here too!

    "Great blog post, Michael! As a passionate developer, I too struggle with those issues you mentioned. As software craftsman professionals, not only do we concern ourselves with best practices when writing code, but also best practices in the process of developing software (e.g., waterfall, Agile, XP, etc.). In regards to writing code, I've found that choosing which practice to use over another depends on various issues. Such as, is this practice introducing something new to the code base for the better or is it following certain conventions consistently or somewhat consistently applied throughout the code...or...should this convention be changed throughout the code. In my 16+ years of experience I have developed software for many different projects. When starting out in a new project, I usually apply what comes naturally at first but then will change if necessary if it doesn't meet appropriate standards already established by the team. Luckily, we have great built-in refactoring tools that help make this easy for us. I think the important principle or question to keep in my mind when writing code, is...Does this code make sense? Will it be easy for other developers, my team mates, to read and follow? Is it understandable, maintainable? There are lots of things to think about, right? Making these types of decisions quickly and efficiently is a necessity for a software business that strives to produce high quality software that is adaptable to change. I feel for the small startups that genuinely have that objective in mind but cannot always achieve it because of budgets, deadlines, pressures from investors, etc. In those types of situations, especially for startup teams that aren't very knowledgeable in best practices, having one individual that is may make all the difference. I'm well aware that this individual may experience a lot of frustration and trying not to be discouraged will be difficult. I believe it will take a lot of patience and remembering the fact that a little can go a long way. By introducing at least a little [best practice] at a time and educating or sharing with fellow developers on what he/she has learned, that individual can make a huge impact on the success of the team. I know...I sound like quite the optimist. :-)"

    ReplyDelete