You are currently browsing the monthly archive for February 2011.

In the first post, I created the confirmational aspects of a simple event registration web site.  Now I am well set up to use that to drive the functional aspects.

Implement the Functional Behavior

The Existing Event Spec

Let’s look again at the main part of event-spec.js:

  'An Event': {
    'when asked for guests': {
      topic: function () {
      'should return the standard guests':
        function (err, guests) {
          assert.deepEqual (guests,
            ['Bob', 'Sally', 'Tim', 'Joe']);
  'when registering Bob': {
      topic: function() {
        Event.register('Bob', this.callback);
      'should return Bob':
        function (err, guest){
          assert.equal(guest, 'Bob');

Adding Event Registration Read the rest of this entry »


I’d like to introduce a new software development technique that is reminiscent of TDD, but at a higher, feature-oriented level. It’s based on the observation that features have both a confirmational and functional aspect. In brief summary:

  • The functional aspect is the mechanism used to bring about a result
  • The confirmational aspect is what lets the user know that their desires and goals for using the software have been met.

The key to Feature TDD is to build the confirmational aspect first, which then serves as the ‘test’ for the subsequently developed functional aspect. Here are the steps I’ll be using:

  1. Capture vision and intent through literal confirmational representation
  2. Pin output of #1 via test
  3. Make vision templates data-driven
  4. Extract data model and create functional stubs
  5. Implement functional behavior
  6. Use techniques #1 and #2 to create functional user interfaces
  7. Link #6 to functional behavior created in #5

In the post, I’ll cover steps #1-#4. Read the rest of this entry »

Once I realized that software features had a duel confirmational and functional aspect, I began to see that pattern at all levels. While it is much more apparent in transactional or workflow application, it can be found anywhere in software.

Keep in mind that currently, because it is traditional written after the functional part of the feature, the confirmational aspects may be missing or poorly implemented. Google does a pretty decent job on simple usability, so let’s look at Gmail for a visible example of the conformational versus functional aspect of features.

Sending an Email

When I send an email from GMail by clicking the send email button, I am exercising the functional aspect of sending an email. My button click causes browser code to execute and a call gets made to the server which uses SMTP to send that message to the recipient(s):

Read the rest of this entry »

It has been said that to be successful in software we need to do ‘The Right Thing Right’. The second ‘Right’ is about Technical Excellence, to which there is already much attention. The first ‘Right’ is more problematic.

Iterations introduced a way to tame chaos by successively asking ‘is this right?’. User Stories and XP’s on-site customer foster collaboration, but that conversation is typically about ‘what the system should do’ with the Product Owner left, in scrum terms, responsible for ROI.

ATDD formalized this concept into a set of system inputs and outputs that are meant to represent that ‘if the system can do this’ then it is assumed that we (the development team) have ‘delivered the right thing’.

There are major weaknesses to this model: Read the rest of this entry »

I keep harping on the bad practice so prevalent in software development of focusing on functional requirements rather than how the system will prove value and make the customer happy (the “satisfaction of desires”). The first conversations we should have with our customers (or about our customers if we’re working with proxies) should start at the hypothetical point after the software has been used to bring about a result (what I call a “mechanism of fulfillment”).

In addition to better understanding of what is going to make the customer happy, this technique also reveals the subtle complexities of different roles within the customer, leading to a map of the different “value constituents”.

I introduced this technique in a work group meeting a few weeks back. It was a mix of product managers and developers and the focus was on a high-level integration of two products.  Before hand, one of the product managers had attempted on their own to define some roles and tasks.  Here’s what he had come up with (specific technologies scrubbed into alpha letters): Read the rest of this entry »

I’ve been chewing on Dan North’s “Programming is not a craft” post and subsequent reactions for the past couple weeks. I have come to the conclusion that I agree with what I think Dan is asserting; however, the critical point isn’t so much craft versus trade as it of utility versus construction. Let me taking a stab and laying it out in a different manner.

Success in software depends on doing the right thing right. The SCM has been focused on the second part of that equation. “Clean Code” ensures that whatever we are going to build, regardless as to whether the utility has been validated, we do it well. In that regard, we can call the code (the implementation meant to fulfill a requirement) “well-crafted”. In addition, part of that craftsmanship ensures that if there is volatility or evolution in the understanding of utility, it can be modify in the most effective manner (usually measured as a matter of time) both in terms of delivering that change and in not breaking things that were not meant to change.

So I think we can put the gold star on “code craftsmanship” and get behind the work the SCM is doing in this regard.

The problem is with the first half of the “right thing done right” equation. Imagine for a minute that a plumber installed a toilet and all of the details of the work were executed with the expert hand of a true craftsman, except that the toilet was installed in the wrong place. Now the house building metaphor is problematic for software comparisons for (at least) two reasons: Read the rest of this entry »

Marty Nelson

The Agile Architect

Latest Tweets