About the project

There are a whole bunch of smart people trying to teach us how to write good software and how to apply software design patterns and principles properly.

The problem is that they seem to be too smart. These people tend to use confusing terminology and high-level concepts, assuming that everybody knows what they mean.

If we were that smart, we wouldn't be reading about how to build blogs or simple CRUD apps. We would be flying above the clouds with gods, hacking around and moving mountains with the power of Clojure or Erlang.

The goal of the "Rails Hurts" project is to discuss the problems of good software design avoiding academic terminology as much as possible. Whenever you find a word with an unclear meaning on this site, let me know immediately in the comments that it needs to be clarified.


Why it is so hard to learn about good software design?

We've already accepted too many axioms about what it means to write good software and how it should be written. We've accepted them undoubtedly, and it is often impossible for us to look at the situation from a different angle.

We just don't have enough free space in our brains for that!

What to do with this?

First, we should unlearn delusions we have in our heads. Then defragment existing knowledge, freeing space for new concepts and approaches.

Finally, we should start applying smarter strategies in our day-to-day job to develop "awareness of a context" (i.e., when something should be used and when it shouldn't).


Take a look at the “Principles and mottos: misunderstood and applied” series.
It questions some of thoughtlessly accepted mottos and principles.
As a consequence, it gently forces your brain to think about their real meaning and areas of application.

Follow @RailsHurts