Over the years I have noticed a habit among some developers that I’ve come to call Aphorism Driven Development. Many best practices are taught and remembered through the use pithy statements. Although these statements are easy to remember, they can’t capture the full context and connotations of the practice in question. If someone never learns the context behind the statement, they are likely to violate the intent of the best practice.
Several examples of this were captured in the Best Practices Gone Bad series. The most obvious being BPGB: Unnecessarily DRY, where people use the aphorism “Don’t repeat yourself” to mean don’t replicate code when the Pragmatic Programmers explicitly said it meant to not duplicate knowledge. Most of the slogans I’ve seen about length of line, method, function, class, or file take a quick rule of thumb intended to get you to think, into a hard-and-fast rule.
The problem with aphorisms is that most decisions in software do not have an actual perfect answer. Most designs are the results of numerous trade-offs. These trade-offs are very much dependent on the particular details of the problems you are solving. A short aphorism does not cover most of the trade-offs you need to consider.
This is not to say that these aphorisms are useless. When you fully understand the context in which the aphorism was intended, you can decide how much weight to give it. If there are no extenuating issues, or if you don’t know enough to make the trade-offs, applying the slogan literally is probably not a bad first solution. Just be prepared to adapt as you learn more.
Conclusion
When you find yourself or someone on your team pulling out a slogan to justify a design decision, you might want to make sure that you are considering the intent of the best practice, not just the slogan. If two (or more) people are arguing about the meaning of a slogan, it might be a good idea to go back and make sure the team understands the full meaning and trade-offs of the practice. It may not seem like it’s worth the time now, but if the team works together for long enough the time saved and arguments avoided will be worthwhile.