An Introduction to Outcome Driven Software (ODS)

For the past year or so, I have been working on a new technique for creating software. I was frustrated with the disconnect between the efforts of development teams (both those I have been on and those I have helped manage) and the outcomes the software was providing when it was actually used.

TDD and other technical practices (exemplified by the Software Craftsmanship movement) are great for validating the correctness and quality of the code, but how do we establish the validity and quality of running software for its intended use? (No, I don’t believe ATDD solves that problem. I’ll dive into the differences in a bit).

Outcome Driven Software (ODS) represents a new way to create software. In short, it is a way to make software by first creating the demonstrative outcomes that will prove validity, then using those outcomes to drive the creation of the functional systems to support them.

Support the Irish Language Kickstarter Project

UPDATE! Thanks to your support, the project has succesfully funded:

http://www.kickstarter.com/projects/242604490/irish-language-hunt

Thanks again to everyone who helped out!

‘Software Is Massless’ – My SAO TechIgnite Talk

Last month I had the opportunity to experience the thrill-ride of a five minute Ignite talk at SAO’s first ever TechIgnite event.  Here’s the intro description and video:

Software Is Massless

Our approach to software creation is largely based on our experience of constructing and interacting with physical objects. Software is massless and moves at the speed of light, so why do we delay our high aspirations for ecstatic outcomes and allow them to fade as we labor on structure, mechanisms and infrastructure? The time has come to break these self-inflicted chains that hold us back from our true potential as wizards of creation.

Lifting the veil, I’ll show you how to reconnect with the power to empathize and collaborate directly with customers and users to create the most important, meaningful parts of your software right from start instead of falling down the rat hole of system design. Then see how this inversion of fulfillment simplifies and minimizes the creation of the system necessary to support the outcomes that have already been created.

 

The ‘Systems Thinking’ Trap and How to Use ‘Empathetic Visioning’ to Avoid It

The problem with ‘systems thinking’ is, well, thinking about the system. It is a trap to envision creation as a set of processes, steps, or mechanisms that need to be ‘figured out’. It typically results in either building predictable, yet uninspiring, solutions for known problems (clocks^[1]), or ineffectively searching by trial and error for solutions to unknown problems (clouds^[1]).

We should set aside “the system” and “thinking” entirely. Instead, focus on a moment in time after the system has already been used and ask what is required to bring about positive emotional outcomes for the participants. This is a different type of labor, one Seth Godin in his book Linchpin describes as “emotional labor” (read about or read on Seth’s blog or one-minute video). I refer to it more generally as just empathy.

It is effective because it allows us to directly envision what will delight and fulfill the emotional needs and wants that truly drive human behavior and satisfaction. It also liberates us creatively because we temporarily remove any focus on the constraints of what the mind believes is possible in the construction of any system.

If we start by this process of “empathetic visioning”, then the subsequent use of systems thinking is done with a clear knowledge of the set of outcomes that must be produced to support the vision. In my experience thus far (it forms the basis of Feature TDD), this reduces system problems to either trivial concerns or makes them well suited to solving by traditional analytical creativity.

^[1] From Karl Popper, I was recently introduced to the concept by my father who sent me a link to Gaurav Mishra’s interesting post on applying clocks or cloud to social media.

Is Empathy the Practice of ‘Customer Pulls Value’?

I’ve been having a hard time seeing what the practice of the lean principal ‘customer pulls value’ means in the context of creating software. The only true pull I could think of is a crowd sourced backlog. That’s useful some of the time, but not in all cases. Otherwise, it seems that some type of stimulation needs to occur (‘pull on behalf of’).

This leads me to two possible (and not mutually exclusive) conclusions:

1. ‘Customer pulls value’ is not a principal, but rather is itself a practice (a technique to be used in certain contexts) used in support of a principal such as “customer co-creation and collaboration” (in which both push and pull occur).
2. We recognize empathy as the practice that supports the ‘customer pulls value’ principal, as it can be proactively initiated while fully maintaining receptivity to pulling.

From wikipedia:

Empathy is the capacity to recognize and, to some extent, share feelings (such as sadness or happiness) that are being experienced by another semi-sentient being. Someone may need to have a certain amount of empathy before they are able to feel compassion.

Early Jumping Mouse Photo

1. Right-side: in jade designer
2. Left-side: duostack hosted (in chrome)
3. Bottom: iPad

 

Feature TDD Example with node.js (2 of 2)

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:

vows.describe('Event').addBatch({
  'An Event': {
    'when asked for guests': {
      topic: function () {
        Event.getGuests(this.callback);
      },
      '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

Feature TDD Example with node.js (1 of 2)

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.

Confirmational versus Functional feature aspects in GMail

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):

Why we need to evolve the agile methodology

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: