A definition before we start:
intentional, a. (n.)
1. Of or pertaining to intention or purpose; existing only in intention. intentional fallacy: in literary criticism, the fallacy that the meaning or value of a work may be judged or defined in terms of the writer’s intention
2. Done on purpose, resulting from intention; intended. Rarely of an agent: Acting with intention.
The Oxford English Dictionary, 2nd ed
If you do much reading about good coding practices, it won’t be long before you come across the phrase “Intentional Programming” which is claimed by Charles Simonyi of Microsoft. Read Kent Beck or Martin Fowler you’ll soon be familiar with the Composed Method pattern and its handmaiden the Intention Revealing Selector. Kent Beck wrote an entire book about the tactics of programming that turned on the concept of the composed method. If you truly grok this pattern then more strategic patterns flow naturally from it.
Kent has said that he views comments in code as indicative of either insufficiently well factored code or of badly named methods. From this viewpoint, Intentional Programming is writing code that makes our intent clear to anyone reading the code. Computers don’t care about style (or anything else for that matter). Humans care deeply, even if they don’t realize it. So, given a choice, choose to express your intent clearly.
That’s one way of reading Intentional Programming. An equally important way is to look at the second meaning of ‘intentional’ in that definition. In the light of that, ‘Intentional Programming’ becomes “Deliberate Programming”. Programming you’ve thought about.
In Perl Best Practices, Damian Conway writes about moving from intuitive to conscious programming. The practices he recommends reinforce each other. Once you can apply them to your own practice, you’re a long step down the road to writing clear, intention revealing code. When you code ‘intuitively’ your choices don’t happen by magic, they use up mental resources but you don’t notice it. If you follow the kind of good practices Damian suggests then you still make choices, but the framework in which you’re making them helps you to make good choices more often.
It’s not just programming of course. I’m a singer. When I learn a song, my starting point is to learn the words. Only when I don’t need the words in front of me can I start to learn to sing the song. Singing for an audience isn’t like singing at home; there are things you should be doing to put the song across. I learn the words because it’s easier that way: I can concentrate on conveying my understanding of the song’s emotional weight to my audience. The investment of learning the words pays off every time I perform the song (and allows me to use each performance as an opportunity to learn how to sing it better).
Learning to program intentionally is another investment that pays off every time. It is easier to read code that follows good practice and we spend more time reading code than we do writing it. Or, in Damian’s words: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”.
Here’s a short reading list of books that are helping me move to a more intentional way of programming:
- Smalltalk Best Practice Patterns – The best advert for the Smalltalk way ever
- Refactoring – Martin Fowler demonstrates the art of leaving code better than you found it
- Test Driven Development – More from Kent Beck and worth every penny