We actually used this strategy—my teammates and I, under Pete's leadership—on a project while I was at ThoughtWorks called EMB. It worked well, and I do think it's a sensible approach. My feelings on the subject don't end there, though. My opinion is a little more complicated than a simple thumbs up or thumbs down. So I thought I'd take a minute to write out my thoughts.
Real constraints and artificial constraints
In any line of work, there are going to be constraints. Some are real—by which I mean, there is no avoiding them—while others are artificial, constraints we impose on ourselves.
A grammar example would be "Never end a sentence with a preposition." This isn't an actual rule of English grammar that you'll find in any grammar book.1 It's just a guideline English teachers use to keep their students from saying things like "When's dinner at?" Meanwhile English speakers all over the world ask each other "Where are you from?" and "What company do you work for?" without even the strictest grammar snobs stopping to correct them.
An example from the programming world would be the Microsoft guideline for C# developers to not use the
readonly keyword on fields of mutable reference types (like
List<T>). Again, this isn't really a rule; in fact it isn't even a principle of good design. It's simply a way to protect developers from their own ignorance. The advice is meant to prevent a dev from thinking that by marking a field
readonly he has achieved immutability. There are plenty of C# developers ignoring this guideline, who know what the
readonly keyword does and use it to prevent reassignment while fully understanding it does nothing to make an object immutable.
A common theme with artificial constraints like the examples I've given is that they are willfully overzealous. They place extra restrictions on their respective domains in exchange for added protection.2 This is a reasonable tradeoff when you just want to use a tool, but you aren't especially concerned with mastering it. You'd much rather play it safe and avoid egregious errors than try anything advanced and possibly make a terrible mistake.
Artificial constraints are training wheels
How many of our literary heroes do you think took the "Never end a sentence with a preposition" rule seriously? Faulkner wrote from the perspective of a mentally disabled person, throwing proper grammar out the window. Mark Twain used nonstandard spelling all the time to capture the voices of his characters. James Joyce was famously experimental, not only with his language but even with the format and layout of the pages in his books.
Someone who's just trying to get by without shooting themselves3 in the foot rightly has a very different view of artificial constraints than someone who wants to be a master. If you're writing a user manual or some documentation, you might prefer to follow stricter rules (to prevent mistakes and avoid any ambiguity) than if you're setting out to write a novel. If you want to be like Faulkner or Twain or Joyce, you're less concerned with following all the rules. In fact what you really need is the confidence to bend language to your will.
I'm not going to convince anyone that code is art if they don't already lean that way; but I'm sure we can at least agree that it is a skill, and some are closer to "mastering" it than others.4 And my key point here is that on the road to mastery, artificial constraints may serve a useful purpose for some time. But they can eventually be discarded, or at least demoted from rules to options, just like training wheels.
Mastery of a programming language
this most of the time, simply because that was the environment in which I learned the language.
this keyword is close enough to, say, Java's, that it feels familiar, so they reach for it. And then they get into trouble, because Java's
So I sort of view
this. On the other hand it's actually a style that requires a better understanding of closures (as a state mechanism) than many devs have. So it straddles the divide between wanting protection and pursuing mastery.
When to embrace artificial constraints
With that in mind, I propose the following simple distinction:
thisand use closures for state" is an option to be considered, not a rule to be followed. You can and should discuss such options as a team and make sure everyone understands their pros and cons, and what problems they're meant to solve.
And if you're on a team where language mastery is not a primary goal, but it's important to you: respect the team's decisions, follow the style that everyone agreed on, and just know that one day when you're ready you can take those training wheels off if you want to.
Of course, grammar itself is mostly a collection of artificial constraints; but I'll save that for another post! ↩
Hmm, giving up some freedom in exchange for protection? Sounds familiar! ↩
Since we were just talking about grammar, how about this one? If you're a stickler, you may have noticed while reading that sentence that someone is singular and they is plural and so I must have made a mistake. But Google for "singular they" and you might be surprised what you find. ↩