The Agile Micro ISV Blog

“If you don’t understand it, you can’t program it.

If you didn’t measure it, you didn’t do it.”

To a Micro ISV, every activity counts. 24 hours in a day - 
Support, bugs, marketing, accounting, sleeping, it all has to fit in.
Since I stumbled into the Micro ISV world, blinking at the Sun, I’ve
seen many strategies and tips for helping focus, purpose and
productivity. But of all the activities undertaken by the micro ISV, it
seems to be the act of writing software that receives the least
attention. At least that’s how it seems to me.

I’ve seen many bright folk expounding the merits of fag packet
design, sketches, notebooks and so on, but I don’t think I’ve seen
anyone expound the merits of an executable specification.

What is an Executable Specification?

An
executable specification is a group of software modules that specify
the design and behaviour of your system. And because it is executable,
you will know almost instantly your behaviour or design is broken.

There are many tools available for the production of executable
specifications, although they’re seldom called that. Out of the Agile
movement came Test Driven Development (TDD), with it’s unit tests and
xUnit frameworks. The *only* problem with TDD when it is done well, is
the nomenclature. Test Driven Development has nothing to do with
testing. It is not a testing activity. It is a specification activity.
And if done properly, the writing of these specifications will really
boost your focus and productivity.

Conventional software development wisdom could be phrased as Design,
Code, Test. Using a specification process like TDD or BDD (Behaviour
Driven Development), the wisdom would more like Specify, Code, Design.
I think it was Kent Beck (the originator of TDD) who paraphrased it as
Red-Green-Refactor.

1. Write a small, granular specification for the behaviour you are
   implementing. Run the specification to make sure it fails. It is
   *supposed* to fail, because you haven’t written the code to make it
   pass. Red light.
2. Write the code to implement the behaviour. Don’t worry about the
   design too much, just get the behaviour right. Now re-run your
   specification, ensure that it now passes. Green light.
3. You know understand enough about your behaviour to implement the
   best design. Here, we remove all duplication. We implement the simplest
   design to support the *current* level of functionality. Refactor.

Your activities become extremely focused on the here and now. You’re
not worried about the impact on your design that some future
functionality might have. The red-green-refactor mantra will help keep
your coding activities lean and mean.

There are numerous other benefits for the Micro ISV:

• Bugs don’t come back. To fix a bug, you write a specification
  that fails because of the bug. You then fix the bug in the familiar
  red-green-refactor mantra. If it ever comes back for some reason, your
  specification should show a red light.
• Increase your confidence in your product.
• Produces well designed code.
• The no-duplication rule keeps maintenance costs to a minimum.
• The specification suite serves as extremely good documentation
  should you take on more staff. Paper documents can lie. Code can’t.

One of the important benefits is this – because you are keeping your
design the simplest it can be for the *current* level of functionality,
your RoI is always the highest it can be in terms of the value of the
product. In other words, if you spend a week implementing architecture,
or framework code to support future functionality, you have spent a
week without adding value to your product, thus decreasing your RoI.

In part 2 we’ll look at an example specification for a simple class.

It’s been an interesting couple of weeks for the NSpec
project. For readers who don’t know what it is, it’s a behaviour
specification framework for .Net, specifically targeted at 
practitioners of Behaviour Driven Development. A while ago,  myself and some other active members of the BDD .Net community agreed to merge NSpec with NBehave, a cousin in the BDD .Net arena.

Joe Ocampo has spearheaded
the integration, and I’m happy to confirm that the integration is
complete, and NSpec itself will soon cease to be. Long live NBehave.

It’s new home is here.

Microsoft have also offered to sponsor the project, which is mighty nice of them.

I
like the notion of “early RoI” and “metronomic delivery” forming part
of a black box definition of Agile. The black box definition seems to
be an embodiment of the customer’s bill of rights. Therefore, to a
customer, a development method could be considered Agile if…

• It allows the customer to plan on a large scale with costs and options.
• It allows the customer to set development priorities weekly.
• It allows the customer to see progress
  in the form of a working system at the end of the first week, and to
  see a little more functionality every week thereafter.
• It allows the customer to get updates on the schedule, good or bad, as soon as the information is available.
• It allows the customer to change his/her mind without paying exorbitant costs.

So in theory, to a customer, nothing else should matter, as long as the process seems agile to them.

To a Manager, we have the grey box. So a development method is Agile if…

• It affords the manager an overall estimate of costs and results, recognising that reality will be different.
• It allows the manager to move people between projects without paying exorbitant costs.
• It allows the manager to get monthly updates of progress, and to help the customer set overall priorities.
• The manager has the right to cancel the project and be left with a working system reflecting the investment to date.

To a developer, we have the white box view of Agile. So to them, a development method is agile if…

• It allows the programmer to estimate work and have those estimates respected by the rest of the team.
• It allows the programmer to honestly report progress.
• It allows the programmer to produce high-quality work at all times.
• It allows the programmer to know what is most important to work on next.
• It allows the programmer to ask business-oriented questions whenever they arise.

Each of the definitions is inadequate in
itself. Perhaps we need to acknowledge that Agile looks different from
different angles.