In our work as software developers we regularly have to evaluate architectural tradeoffs. We have voices, either external or internal, telling us to think about, for example:

  • Going API first
  • Building to accommodate horizontal scaling
  • Building with the most modern tools
  • Building with tools and frameworks that let us hire the best (or sometimes “Building with tools and frameworks that let us hire the cheapest”)

There is often a tension in these matters between practical and “correct”. It may be most correct, for example, to build up your styling and javascript components from scratch, such that you only introduce precisely the code you need to realize desired functionality. There may be something intuitively less correct about bringing in styles and components that you never actually end up utilizing, such as happens in some degree when you build atop, for example, a UI framework like Bootstrap.

Firsthand experience has repeatedly shown me, however, that the teams who favor the correct over the practical approach get burned in far greater degree than those who favor the practical over the correct. Perhaps at an extreme operating scale this ceases to be the case, but in my work with sub-100-person teams, it reliably and repeatedly is.

I believe that there are a few essential reasons that teams favoring the practical over the correct seem to have disproportionate success. Certainly one obvious reason is that mature frameworks like Bootstrap have comprehensive documentation and strong conventions. If a new developer is unsure how to adjust the color palette, she can find a resolute answer in documentation, and the code changes she makes will be the exact code changes that future developers expect to see (and if these future developers don’t understand what is going on, they, too, can find out by reading the mature and thorough documentation of the framework).

I also believe that there is a less obvious force at work. That is that the team that operates this way is more likely to be composed of mature developers. Mature developers have lived through hype cycles and are often much less interested in trying out cutting edge tools for the heck of it. They usually have deep experience with mature – if less exciting – stacks and are most interested in servicing the needs of the business over more academic ends (if the broader outcome is something worse-documented that is harder to develop against and maintain).

Other good, real-world examples of questions of practicality over correctness include:

  • Microservices vs. Monolithic Architectures
  • Declarative JavaScript (or CoffeeScript) “sprinkles” vs modularized ES5/6
  • Server-rendering vs Single Page Application architectures
  • Full-stack frameworks like Ruby on Rails vs additive microframeworks like Sinatra
  • Single/dedicated vs Multi-Tier deployment schemes

Broadly, there are ultimately places for the “correct” path. Experience just repeatedly shows that favoring the correct path largely for the reason of correctness is a mistake.