The Truth About Best Practices

July 8, 2007 by
Filed under: Process, Project management 

It is likely that “best practices” is the most overused term in software development today. Anyone discussing what needs to be done to improve the situation on projects will use the term. It is the basis for almost any consultant’s pitch. We train in best practices, we study and promote best practices, and we still face challenges. What is it about these best practices that makes them so compelling, and why don’t they seem to work as well as consultants would suggest?

The term “best practices” is not new. The idea of activities or techniques that are the most effective at solving problems was bantered around in the early 1900’s. There are best practices in manufacturing and agriculture, among others. There are Generally Accepted Accounting Practices (GAAP) – while not quite best practices, they are an expression of the way things are done for accounting.

For any practice to become a good practice, it needs to be shown to be effective in the real world. To become a best practice, it needs to be seen as the most effective approach to accomplishing a goal, in a repeatable fashion over a large sample space. Let’s consider each of these achievements, good and best, in turn.

There are many practices that have been shown to be effective in the real world, with truly amazing results. Studies in formal inspections, for example, often show a return on investment as high as 10:1. A dramatic reduction in lifecycle costs, and improved delivered quality. Most other practices demonstrate less compelling results in studies, but many are still seen as worthwhile investments. Iterative lifecycles, change management, software reuse, prototyping, metrics programs. They are all good practices, and the overall list is far too large for this forum.

All of these practices have been shown to work on real projects. Certainly the literature leans toward publishing the results of successes in applying these practices. Quantified data from my clients indicates that there are strong correlations between many of these practices and improved performance on teams. Actually, this data shows that these practices have a stronger positive correlation to performance than any demographic element in the study.

But are these best practices? Because projects and project teams come in all shapes and sizes, it is never safe to say a priori that any practice is the most effective approach a team can take on. While formal inspections can provide tremendous value for some projects, cultural considerations may make this practice difficult to implement, or even counterproductive with some teams. You could easily make a similar argument for any of the practice that is discussed. From that point of view, when we are talking about software development in general, the term “best practices” is hyperbole.

Under the right conditions, though, many of these practices can be very effective. This is the key point, that any practice is only situationally valuable. Short agile iterations may make sense for some projects, while deep analysis and design would better serve other projects. Some cultures may easily embrace a flattened, distributed decision structure, while others thrive under a stronger hierarchy.

The fact that ‘it depends’ whether a practice makes sense to apply is generally lost in software development. Consultants will pitch their specific flavor of practices as the solution without regard for the client situation, and sometimes the results are disappointing (how often is the consultant held accountable?). On teams, we tend to accept the advice of consultants without deeper study of the ramifications of our actions. We try to apply best practices, and find we are often disappointed with the results. We conclude that this process improvement stuff doesn’t work.

One of the most widely exposed catalogs of best practices is in Steve McConnell’s Rapid Development. The last third of the book consists of 27 best practice chapters, each one selected as an effective way of optimizing speed on projects (indicating that there are other practices that optimize other factors). A critical part of each of these chapters is an identification of the situations where the practice is effective, the major risks associated with the practice, and the major interactions and trade-offs. Again, this information is often overlooked during the consultant’s sales cycle, and neglected by many practitioners.

This may be one of the reasons why Fred Brooks asserted in his No Silver Bullet essay that “The gap between the best software engineering practice and the average practice is very wide – perhaps wider than in any other engineering discipline.” This assertion was made in the context of expert systems that could someday disseminate the “experience and accumulated wisdom of the best programmers” to inexperienced programmers. We’re still not there over 30 years later, and the gap remains wider than it should be.

(Don’t get me going on why even the most revered experts persist in thinking of practitioners in software as programmers. If we are doing our job right, programming is but a small part of what we do.)

So there are many good practices, each having merit in some situations, but the insight of how to select and apply them is not generally exposed or recognized. Schools tend to emphasize technical skills because that is what the industry demands, and many of the practices we talk about are largely ignored or simply covered in a survey course. Many development teams rely on technical skills and heroic efforts to complete their projects. For many of the good practices that have been identified, in my experience there remains an alarmingly low rate of adoption. There are very few teams with disciplined estimation techniques, there are generally glaring omissions in analysis and design on projects, there is little conscious selection of project lifecycles. Similar gaps exist for any practice I can think of.

On top of all this, it is important to recognize that there are other factors that drive project success. We can’t just build a product and automatically be successful. The product needs a market, and the message needs to find that market. There is as much science in all the other disciplines as there is in product development, and any aspect of the business can make or break product adoption. Some would suggest that luck and timing play a major role as well.
With all the factors outside of software development, the apparent cost required to select and implement practices that improve product development, and the experience of poorly managed change, it is no wonder that best practice discussion quickly fades in most shops.

There are no best practices, only good practices that may help you if the situation warrants. You need to be aware of the practices, understand whether it makes sense to apply them, and then apply them correctly. This entails a great deal of effort and discovery, but done right, the payoff is enormous. With all this, there are no guarantees of success, as the most effective practices for your situation may be outside the software development discipline altogether. – JB


Feel free to leave a comment...

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    If your desire is to effect change or have more influence on a software team, you could either stumble around in the dark for a few years, experimenting with different techniques, or you could buy, read, and apply the techniques in this book. This choice, of course, is up to you.

    — Matt Heusser