Home > habits, programming, tools > Tools of The Effective Developer: Programming By Intention

Tools of The Effective Developer: Programming By Intention

September 25th, 2007






Be Sociable, Share!
Categories: habits, programming, tools Tags:
  1. September 25th, 2007 at 11:13 | #1

    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.

    • September 25th, 2007 at 11:49 | #2

      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.

  2. September 26th, 2007 at 21:52 | #3

    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.

    • September 27th, 2007 at 07:49 | #4

      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.

      • September 27th, 2007 at 18:00 | #5

        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. =)

        • September 28th, 2007 at 14:20 | #6

          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?

Comments are closed.