Tools of The Effective Developer: Programming By Intention
This is the third post in my Tools of The Effective Developer series. The other two discussed the habit of keeping personal logs, and the habit of daily planning. Now the time has come to the habit of programming by intention.
Please note that I’m not speaking of intentional programming, which by the way introduces some interesting concepts. Instead I refer to the simple kind that only requires your brain and the programming language of your choice.
So what is programming by intention? Well, I like to describe it this way: if you are to implement a new set of functionality, and you don’t start with the implementation, nor the programming interface, but you start writing the code that is going to use it – then you are programming by intention.
Why is this way better? The short answer is: Because we are lazy. The long answer is: We humans usually seek the simplest solution. Start with the utilizing code and you should find yourself pushing complex code and decisions right where it should be: behind the programming interface, nicely encapsulated. We also focus more on the task at hand, which decreases the risk of committing the sin of premature generalization.
Programming by Intention is probably the easiest effective developer habit to acquire. It can be done at all levels of abstraction and there is no overhead cost. Therefor it’s my favorite habit.
Ok, this is a big shock to me. I thought this was the only way you could realistically write software. There are people who write parts of their software before it is used? How does that work?
BTW, the “the simple kind” link is probably the worst thing I’ve read in a very long time.
Thank you for the comment. To answer your question, it could be something like this:
a programmer realizes: “In order to implement THIS, I’m gonna need THAT”. So he sets off to work on THAT instead of THIS. In my experience, a common scenario.
For instance, when building a ray tracer many people would start off by implementing a set of types and helpers that they know they are going to need. Then they might go on by implementing a general object structure to contain the object-ray intersection code. Simply put: they write the utility code before the code that utilize it. Thus they are not programming by intention. I used to be one of those programmers.
I’ve done this for a while and coined the term “Usage-Driven Development”. Not sure if it’s actually a term or not, but it seems to convey the concept pretty well.
It’s a very easy way to be able to make something complex very simple ( at least for your interfaces ). Write the usage code first, and keep rewriting it until it is as simple as it can possibly be. Only then do you tackle the class, starting with the public members.
I like the term you coined. It sounds modern. If it were to be publicly accepted we would have Test-Driven Development, Behavior-Driven Development (which is almost TDD and Programming by Intention combined) and Usage-Driven Development; all closely related terms.
But since TDD and BDD are test-based techniques while UDD is not, I think I’d vote for the XP-term: Programming by Intention. Just to avoid confusion.
Heh personally it fits right in for my book, since it’s not really that far off from something like TDD. In fact, you can take the Usage you create and use that for your TDD if you’d like.
So my first step is to put block comment at the header of the new class and work out what I’d like the interfaces to be in the “sample usage”. Then start creating them, then use that sample usage code to derive my tests. =)
So you are practicing DDD, Document-Driven Development, cool. 🙂
I must admit I am lousy at documentation. I try to write self-explaining code, but necessary documenting stuff like sample usage is often sadly left out by me. Your process sounds like a great way to fix that.
I still like to start with the test though, but I should be able to do it the other way around: cut and paste test-code to the document header. Thank you for the (reversed) tip!
BTW: if you combine TDD and your UDD, is that BDD?