I’ve been reading the book Zen in the Art of Archery. It is the true story of the western philosopher, Eugen Herrigel, who goes off to study the craft of Japanese longbow shooting. And if you have any interest in Zen or eastern mysticism I can’t recommend a better introduction.
Interestingly enough, some of the wisdom that flowed out of the book made me think about my own craft, programming.
In the beginner’s mind, there are many possibilities, but in the expert’s there are few – Shunryu Suzuki
Zen has a great concept called beginner’s mind. A beginner is not worried about making mistakes, he does not know of any physical limitations that may be perceived to exist and he doesn’t start his thoughts from within a framework of rules. The point here being that ultimate creativity and out of the box thinking lends itself to someone who isn’t shackled by preconceived notions or "wisdom" about what is possible and what isn’t.
Of course this doesn’t mean we have to throw our training, knowledge, and experience away. But perhaps breaking the rules, and challenging existing ideas every now and again is not so terrible.
Think of the MVC Pattern for a second. A great pattern that has prevented a lot of spaghetti for a few years now. But so frequently it is applied void of any creativity within it’s confines. As if submitting to the pattern means no more thought is required on behalf of the programmer.
I have seen too many instances of a Sheep, ISheepManager, SheepManager, SheepController that make me think a whole generation of Java web developers (myself included) must have just given up. Ultimately submitted to the standards laid down by their wise predecessors.
I remember a team member who wanted to introduce BDD into our tests. During the presentation he wrote
which had a portion of the team instantly, up in arms. “You can’t do that!”. Their conviction so strong you might be convinced this code wouldn't compile. The problem? Java standards which expect CamelCase in method names. A great idea in and of itself, and one that definitely does more good than bad. However the makers of java standards weren't doing BDD, and in this very specific scenario I would have to agree with the team member that
is monstrous compared to the previous example.
I don’t mean to turn this into a debate about the advantages of code conventions. But how can we even pretend to be innovators, when things are not allowed, or even worse "not possible" .
BDD is thriving in the groovy community, in huge part due to it lending itself greatly as a DSL, but I think groovy being new also allows its users more room to exercise their Beginner’s Mind. There are no rules yet, no notions of what is possible and what isn’t.