BDD with intent

3 mins
, , ,

Charles Simonyi introduced himself at a recent workshop with the words: “I was at Xerox PARC in the 70s, Microsoft in the 80s, and working on intentional software in the 90s”. He wasn’t showing off, he was just there. He pioneered WYSIWYG, created Microsoft Word, Excel and Access (as a data visualization tool), championed OO and invented metaprogramming.

What this tells me is that when Charles Simonyi thinks he is on to something, it’s probably worth listening. (Ok, I’ll forgive him szHungarian notation.) For the last 15 years, Charles has been on to intentional programming.

An Intentional Primer

The basic premise of intentional programming is something like this:

  1. We tell computers what to do in computer terms, not in business terms. Even OO languages are guilty of this.
  2. Programmers do two things: translating between business concepts and computer concepts, and then arranging the computer concepts (or more accurately the translations) to get stuff done.
  3. Domain experts, or Subject Matter Experts (SMEs) don’t have a direct line to generating computer systems; they have to go through a programmer.
  4. Once we have understood (most of) the business domain, i.e. we’ve done (most of) the translation part. A lot of systems changes are about rearranging these concepts to do new things.

This means that most of a programmer’s time is spent shuffling existing concepts, or wiring them together in new and interesting (to the SME) ways. Intentional programming suggests that we split these roles of programmer-as-translator and programmer-as-system-generator. The programmer works with the SME to define the business concepts in the form of “intentions”, and then works independently on a program generator based on those intentions. This means that if the SME can represent some new requirement as a rearrangement of existing intentions, they no longer need the programmer to generate a working computer system.

No, this isn’t model-driven development. No-one is suggesting for a moment that programming suddenly became easy, or that it was just a typing exercise all along. There is still a world of subtlety in the interpretation of intentions into stuff-computers-do. All that intentional programming does is cleanly separate the interpretation issues from the issues of expressing the intent in the first place.

This gives us two independent axes for doing development. The richer the intentional vocabulary gets for a particular domain, the more intent the SME can express. As the programmer improves the generator through a greater understanding of the intentions themselves, any system based on those intentions becomes qualitatively “better”. (This is one of the reasons people are getting so excited about domain-specific languages—DSLs—and the consequent interest in languages like Ruby that are good at representing them.)

BDD as a “Poor man’s Intentional Programming”

Behaviour-driven development is about expressing a requirement in the form of expected behaviour. BDD says: “To achieve my intent (the business value of a story), I expect the system to have certain behaviour.” BDD has much more humble ambitions than intentional programming, but interestingly it converges on the same space. It turns out that the stories and scenarios of BDD—its Givens, Events and Outcomes—work best when they are expressed in the language of the business domain. This causes business analysts to talk to testers, and testers to talk to programmers, and they end up having the sorts of conversations intentional programming is all about.

I don’t think we’ll have SMEs arranging code-generating intentions in an IDE any time soon—although Intentional Software are working on some pretty sexy software that might just give the lie to that—but in the meantime I’d like to think that BDD can set people thinking along the right lines.