I belive that, for the overwhelming majority of domains, it is the tool – if weilded with healthy reverence for its conventions and idioms – which leads to the most manageable, consistent, non-redundant and all-around sane codebases.

Nearly every “scaling” or “complexity” gripe that I have heard leveled at Rails is in fact a complaint about non-idiomatic use of the framework. I still routinely stumble on codebases that make zero use of key-based fragment caching (an innovation that elevated Rails far above many other frameworks in performance when it came to real-life application – not just framework benchmarking), poor or incorrect use of the ActiveRecord query interface, poor domain modeling (failing to see when validations or logic belong on relations, for instance, and not in the related objects), failure to design properly DRY controllers (failure to use exception-based control flow and filters where appropriate), heavy integration of and reliance on obviously poorly maintained dependencies, and much, much more.

So accepting now that one can – and, in fact, people often do – make horrible messes of applications they implement with Rails, I will continue to devote myself to its idiomatic application until something comes along that does it all better in the real world. And my real world metrics of success are modest: “is there less code?”, “is it easier to read?”, “does it break less?”. Academic cases for purity should always take a back seat if they result in an outcome that is many times worse by these practical metrics, which is often the reality.

In this time when choices at all levels of your stack abound like never before, it pays to be mindful of what your real-world metrics of success are, and to honestly weigh how closely your stack is aligned with them.

The post Less Code appeared first on Hacker Notes.