Programmers sometimes are given a hard time because they feel passionately about their tools and methodology, and because they express those opinions strongly. Jason Cohen argues for the opposite attitude: Opinionated development is a <em>good</em> thing.
Software frameworks are so opinionated all of a sudden. I love it; we need more of it.
The Agile Manifesto was one of the first clear examples of opinionated expression. No hedging, just clear trade-offs, like valuing "working software over comprehensive documentation." If there's a question between creating a requirements doc or writing a human quasi-readable integration test, it's clear what an Agilist will say.
Ruby on Rails pounds even stronger opinions down your throat, such as the ubiquitous "convention over configuration" precept. Whenever there's a choice, you can be sure Rails will pick a method that requires typing fewer characters.
Most software development practices instantiate a philosophy or mind-set. That’s true of individual teams just as it is for programming languages and software startups and corporate “everybody knows” cultural assumptions. You might not agree with the base opinion (as expressed in the end result or the “how we do things” process), but a strongly shared opinion gives a group its own integrity.
In fact, Rails takes strong opinions to such an extreme that it's not clear whether the trade-off is worthwhile. For example, in RailsGuides – arguably the primary introduction to Rails – when they introduce the Rails rendering engine they specifically point out how cool it is that with an empty controller class you can already produce a working page. But then they immediately go on to say that in practice you always need a non-trivial controller class and proceed to show how to do that.
What's the point in making an empty class work? Isn't it just more confusing and almost never needed anyway?
I could devote a whole post to that question, but that's not the point. The point is that in a global sense, this core decision has clearly wonderful aspects:
- ... which means fewer bugs
- ... which means code that is easier to maintain
- Once a developer learns the conventions, she can be more productive because boilerplate code isn't needed, either in the first place or when maintaining the software.
- A developer new to a particular Rails project can get up to speed much faster because the conventions are common to all Rails projects. There's no thought or discussion about a ton of things which don't matter much anyway.
- Like code styling, almost none of the details matter. It only matters that everyone agrees, and that Rails conventions are the same.
But there are clear drawbacks:
- A person new to Rails spends hours reading just to write a single line of working code, because nothing is obvious from the code.
- When Rails changes convention (e.g. moving to v3), lots of stuff breaks. Plus, it breaks in ways that are hard to enumerate because the code itself isn't obviously wrong. For example, if interfaces change in Java, old code doesn't compile, so it's obvious what needs to change; but not so with Ruby and Rails.
- If you don't have good test coverage, even trivial bugs aren’t caught by your development tools. This leads to silly bugs, or a large number of trivial tests that are a waste of time to write and maintain.
- It's difficult or impossible to write a variety of development tools – like automated refactoring – because the code doesn't contain enough information to do so. This means more code cruft and less tool support.
Is Rails "right?" As a Zen master would say, that's the wrong question.
The question is: Which is the better set of tradeoffs for your project, your developers, your culture, your goals?
What's great about Rails, though, is that they declared that this was a trade-off they wanted to make, and then they stuck to it all the way.
Because what that does is make it clear to we developers that we're making this choice. That means we can have the discussion above and make a choice with eyes open.
The thing is: All platforms, frameworks, and libraries are opinionated too. They just don't declare it and they aren't as consistent about it. And that means it's harder to know what trade-offs we're getting into, as users of those tools. We make poorer choices at the outset and we abuse the tool along the way. Bad!
I assert: Let's not only get more opinionated; let's get better at articulating what those opinions are.
In an upcoming article, I'll list the types of things that software can be opinionated about, so you can be better about being intentional about the opinions you're injecting into your project, or more critical about the frameworks and libraries you choose.
To be notified when part 2 goes up, subscribe to this blog by email or RSS!
And let's continue this discussion in the comments! There's lots of sides to this issue.