Technical Dogma

anchor-954927_1920Humans are creatures of habit, and I suspect that engineering/technical types are even more so. We find something that works and tend to stick with it, sometimes neglecting to occasionally experiment with new tools or methods. The mantra of “If it ain’t broke, don’t fix it” becomes the defense for standing by what we know works just fine.

There is little harm in favoring the old tried-and-true. Where this gets dangerous, though, is when we assume that our favorite solution is the only way to solve a particular problem. Myopic loyalty to a particular set of tools or design patterns is a frequent contributor to square-peg-in-a-round-hole solutions. Even worse, this type of loyalty occasionally causes one to actively campaign against other solutions to the same problem, not on the merits but because “It’s not my way.” This happens at the macro level (always using relational databases over NoSQL, or insisting on one database vendor over another) as well as the micro (design patterns for change detection, or naming conventions for coding.) Little progress can be made when opposing sides entrench themselves to defend their design pattern or choice of vendor.

Loyalty to one’s preferred solution set is fine, but must be tempered with an open-mindedness that there might be new or better ways to solve the same problem. Conceding to a different way of doing things is often difficult for us engineering types, but it can lead to better solutions for our clients and employers.

This article was originally posted in my Data Geek Newsletter.

About the Author

Tim Mitchell
Tim Mitchell is a data architect and consultant who specializes in getting rid of data pain points. Need help with data warehousing, ETL, reporting, or training? If so, contact Tim for a no-obligation 30-minute chat.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.