The mathematician Alfred Korzybski coined the phrase “the map is not the territory” in 1931 as part of his paper outlining the relationship between mathematics and human language.
Broadly, he states that although maps are useful representations of the real world, you shouldn’t forget that they’re not reality itself. They are a necessary simplification of reality that allow us to process complexity. Another word for this is an abstraction.
Programming is full of abstractions. And I suppose the most influential map I’ve encountered in my career is Ruby on Rails.
Frameworks in general offer a level of abstraction that is useful. But Rails takes this to a further level with its fundamental principal of “Convention over Configuration” which DHH eloquently describes in The Rails Doctrine:
But beyond the productivity gains for experts, conventions also lower the barriers of entry for beginners. There are so many conventions in Rails that a beginner doesn’t even need to know about, but can just benefit from in ignorance. It’s possible to create great applications without knowing why everything is the way it is.
One of my biggest takeaways from working across several Rails codebases is that you’ve got to look out for situations where the map stops making sense and starts pushing you in directions that feel uncomfortable. Don’t blindly follow it. You should be open to getting out a red pen and redrawing the key.
- Do all the files in your
modelsdirectory have to be backed by an Active Record object? No.
- Because Rails generates controller tests do I have to write them? No.
- Will the world end if I create a new directory under
rails new app command is so powerful. But it’s a double-edged sword because it leaves you with the impression that these are the only options for organising your code, and in turn how those objects and systems communicate with each other.
Rails is very clear on what it explicitly wants you to do, but there’s plenty of useful things it will implicitly let you do that are good and productive.