Why I'm leary of "Best Practices"

I have been aware of the term "best practices" in software development for at least 20 years, and I'm sure it has existed in our profession and many others for much longer. There is an obvious logic to learning from others' mistakes, and for not reinventing the wheel. But too often the phrase is used to suggest that there is one correct way to accomplish some software engineering task - an attitude I believe deserves close scrutiny.

Technology in general, and software development in particular, moves so quickly that the shelf-life of any practice or approach can be quite short. If I can get 18 months out of a particular solution I am satisfied; any utility beyond that is a windfall. Software should be built quickly and well so that it will deliver a positive ROI in that time frame. (Keep in mind that in order to deliver any benefits the software must be used, not simply delivered - so the time required to build it is just one component of its overall cost when determining ROI).

There are two mindsets in software development that are in tension and need to be balanced. At the extreme, the first is total standardization, and the second is to build everything from scratch. Neither alone is the correct approach, and some middle ground should be sought. In my experience, the best approach for finding this middle ground is to bring together a group of software developers and stakeholders to discuss the pros and cons of various design approaches, with an eye toward maximum appropriate reuse. These discussions can be highly educational as well as lead to a more balanced approach.

Given the rapid turnover of software solutions, it absolutely makes sense to consider "best practices" and to reuse as much technology as possible. However, judgement should always be applied when considering which components and approaches to reuse, and how those selected should be combined into the final product.