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.