Note
This article is a description of just a small part of our development process. Our goal with all of our practices is to enable developers to be just as productive on old projects as they are on new projects.
I'd recommend starting with this article that describes that goal:
In the first chapter of "Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results", Mike Rother tells a story about a friend who observed "flow racks" being used during a Toyota factory tour. What they are doesn't particularly matter, but many people copied this technique for their own production systems. When the friend toured the same factory again, they observed that "flow racks" were no longer in use, and another technique was used instead. Frustrated, the friend asked which technique was better, which was not a question that the Toyota hosts understood. The cognitive dissonance demonstrated here is a result of one party believing that something was a "best practice" and another party recognizing that that practice was a specific countermeasure to a specific circumstance, and that specific circumstances may be limited to specific moments in time.
The software development community is filled with assertions of "best practices". Some of these are downright harmful, while others are merely contextual. It would be ridiculous to consider any practice truly "best". Different circumstances call for different countermeasures. Labeling any practice "best" only has problematic effects.
If something is a "best practice", I should use it. It's the best, after all. That means I won't find anything better, which means I don't have to look for anything better. This flies in the face of the notion of continuous improvement — something that works well today may be improved upon tomorrow.
Furthermore, if it is best, I don't need to examine whether or not it applies to my situation, I just need to blindly follow the suggestion. Those who push or cite best practices often (intentionally or not) want to convince you of something without requiring or asking you to think for yourself. This can stop learning and inquisitiveness in its tracks, but it is very tempting to take this shortcut. Be warned, however, that this is adhering to orthodoxy, rather than practicing engineering and continuous improvement.
We aren't actually going to get better unless we challenge the status quo. Best practices are, at best, average practices. We can always improve. I'd suggest taking a look at anything that your team considers a "best practice" or anything that they hold dear, and asking, "What problem does this solve?" Then, see if there are ways to eliminate that problem or less elaborate ways to address it. You might be surprised.
Subscribe to be notified of new articles
Copyright Aaron Jensen 2023-present