Image via Wikipedia

Required materials:

• Plain Paraffin Wax (about 1/2 pound)
• Double Boiler
• Wooden spoon
• Bowls for cold water
• Candle thermometer
• Kitchen Stove
• Wick

And the instructions:

1. Cut the wax into small pieces.
2. Bring the water gently to the boil. Place wax in the double boiler.
3. Stir until the wax is melted. Once melted, try to keep the wax at 71C / 160F.
4. Cut the wick to the desired length, then dip into the wax. Allow the wax to cool between dippings for a minute or two.
5. Continue the dipping and cooling process. After a few dippings, you can speed up the process by dipping in cold water.
6. Repeat the process until the candle reaches the desired thickness.
7. When finished and cooled, cut a flat base on the candle.

Et voila.

So what’s so interesting about candle dipping from the perspective of software development?
Well, after 1 dip, what do you have? Well, you have a piece of string
covered in wax, neither use nor ornament. But after just a few dips,
you will have the beginnings of a candle, albeit at this stage, a very
slim one. So very quickly, we have something that could function as a
working candle.

Then, over time, we add layers, additional wax, additional
functionality. In time, this candle willl become an impressive church
candle, with a good 4 or 5 inches in diameter. Just as your app, with
very humble beginnings, will, with proper technique, become a very
impressive app.

The use of candle dipping as a metaphor for software development is not new in the world of Agile Software Development.
The essence is that we work in very small iterations, and we keep a
working application available at all times, just as our candle could
function as a candle at all times throughout its creation.
Functionality, business value, mojo, whatever you want to call it, is
added in vertical strips, just like in candle dipping.

If mojo is added in the order of business value, this process will,
at all times, mean that your application will yield the highest return on investment possible at any given time.

As software developers, and particularly as a micro ISV, we would
think of our code base as our biggest asset, but how often do we think
of it as potentially our biggest liability? Why a liability? Because it
costs money. It costs money for others to spend time understanding it
(if you aren’t a 1 man band), it costs money to change it, it costs
money to test it, to bugfix it, to refactor it, to add to it, to
integrate it. These are the times that you will notice the interest
payments on your technical debt.

As a micro ISV, technical debt payments can be crippling. Imagine
not being able to make use of you’re new employee because your code is
too hard to understand, because it does not clearly express intent.
Imagine not being able to add a new feature because you’re too worried
about the impact on the stability of your codebase.

The solution is clear. Don’t let technical debt accumulate to a
level such that the interest paments become a barrier to progress. Your
code is your greatest asset, don’t let it become your greatest
liability.

For the purposes of today, I’m going to say that the interface our stack class will support is as follows: 

public
class
Stack<T>

{

public
Stack();

public
void
Clear();

public
bool
Contains(T item);

public T Peek();

public T Pop();

public
void
Push(T item);

// Properties

public
int
Count { get; }

}

Now, clearly we’re not going to win any awards for the class, but it should serve its purpose.

So what are the first things we could say about it? Well, when the
stack is empty, its Count should be zero, and trying to call Pop or
Peek should cause an exception. So how might we write that in an
executable specification? Well, let’s take the first one as an example:

using NSpec.Framework;

namespace Stack.Specs

{

 [Context]

 public
class
WhenTheStackIsEmpty

    {

  Stack<int> _stack = new
Stack<int>();

        [Specification]

  public
void CountShouldBeZero()

        {

   Specify.That(_stack.Count).ShouldEqual(0);

        }

    }

}

That’s the simplest way of expressing that piece of behaviour. And
I’ll need to implement just enough to make that code compile, and the
spec fail. Here’s what I’m starting with:

namespace Stack

{

public
class
Stack<T>

{

 public
int Count

    {

  get

  {

   return -1;

        }

    }

}

}

And firing up the spec runner, I get:

But making the test pass is trivial, by changing the Count property to:

public
int Count

{
 get
 {
  return 0;

 }

}

Don’t cry foul, we’re not done yet. What else did we say about an
empty stack? We said calling pop or peek should cause an exception.
Taking a bit of a short cut, specifying these two bits of behaviour:

[Specification]

public
void PeekShouldThrowException()

{

 MethodThatThrows mtt = delegate()

    {

        _stack.Peek();

    };

 Specify.ThrownBy(mtt).ShouldBeOfType(typeof(InvalidOperationException));

}

[Specification]

public
void PopShouldThrowException()

{

 MethodThatThrows mtt = delegate()

    {

        _stack.Pop();

    };

 Specify.ThrownBy(mtt).ShouldBeOfType(typeof(InvalidOperationException));

}

These requirements can easily be met with:

public T Peek()

{

 throw
new
InvalidOperationException();

}

public T Pop()

{

 throw
new
InvalidOperationException();

}

Now we have 3 passing specs. What else could we say? Well, when the
stack has stuff in it, we’d like the count to be correct, we’d like to
know whether it contains a particular item, we’d like to be able to
clear it, and we’d like things to Pop and Peek in the right order. So
let’s get started by adding a new Context, and a new spec method:

using NSpec.Framework;

namespace Stack.Specs

{

    [Context]

 public
class
WhenTheStackContainsItems

    {

  Stack<int> _stack;

        [SetUp]

  public
void SetUp()

        {

            _stack = new
Stack<int>();

            _stack.Push(0);

            _stack.Push(1);

            _stack.Push(2);

        }

        [Specification]

  public
void CountShouldBeCorrect()

        {

   Specify.That(_stack.Count).ShouldEqual(3);

        }

    }

}

Now we’ve got some work to do. This doesn’t compile because we don’t have a Push method yet, so let’s add one:

using System;

namespace Stack

{

 public
class
Stack<T>

    {

  int _current = -1;

        T[] _items = new T[10];

// Snip

  public
void Push(T item)

        {

            _current++;

            _items[_current] = item;

        }

    }

}

But shock! We have a failure.

What went wrong? Oh that’s right, we cheated in our initial
implementation of Count, so now it’s time to do it right. In the spirit
of YAGNI (You Aint Gonna Need It) it’s almost always best to fake a
method until you are forced to do it right.

public
int Count

{

 get

    {

  return _current +1;

    }

}

4 green dots and 1 happy camper. So let’s move on to checking whether it contains a certain item:

[Specification]

public
void ShouldNotContain999()

{

 Specify.That(_stack.Contains(999)).ShouldBeFalse();

}

[Specification]

public
void ShouldContainZeroOneAndTwo()

{

 Specify.That(_stack.Contains(0)).ShouldBeTrue();

 Specify.That(_stack.Contains(1)).ShouldBeTrue();

 Specify.That(_stack.Contains(2)).ShouldBeTrue();

}

And some implementation:

public
bool Contains(T item)

{

 foreach (T t in _items)

    {

  if (t.Equals(item))

        {

   return
true;

        }

    }

 return
false;

}

And we’re good, 8 green dots. What next? Let’d add support for clearing:

[Specification]

public
void ClearShouldEmptyTheStack()

{

    _stack.Clear();

 Specify.That(_stack.Count).ShouldEqual(0);

}

Red dot.

public
void Clear()

{

    _current = -1;

}

Green dot. Now on to the fun bits, peeking and popping:

[Specification]

public
void ShouldPopThemInTheRightOrder()

{

 Specify.That(_stack.Pop()).ShouldEqual(2);

 Specify.That(_stack.Pop()).ShouldEqual(1);

 Specify.That(_stack.Pop()).ShouldEqual(0);

}

Again, our earlier short cuts are biting us, red dot. Let’s iron out the wrinkles:

public T Pop()

{

 if (_current > -1)

    {

        T popped = _items[_current];

        _current–;

  return popped;

    }

 else

    {

  throw
new
InvalidOperationException();

    }

}

And for the peeking:

[Specification]

public
void PeekShouldReturnTopItem()

{

 Specify.That(_stack.Peek()).ShouldEqual(2);

    _stack.Pop();

 Specify.That(_stack.Peek()).ShouldEqual(1);

    _stack.Pop();

 Specify.That(_stack.Peek()).ShouldEqual(0);

}

This gives us the same problem as before, so, ironing again:

public T Peek()

{

 if (_current > -1)

    {

  return _items[_current];

    }

 else

    {

  throw
new
InvalidOperationException();

    }

}

There, 15 shiny green dots. We have a rudimentary stack class with
some pretty sever limitations, but in terms of the specifications,
every time we build this code, every time we add to it, or refactor,
every time we fix a bug, these specifications will be here, ready to be
run. Don’t underestimate the confidence these kind of tests can bring
to your micro ISV. Time is precious, and believe me, writing these
specs once, will pay you back very quickly, as it drastically reduced
repetitive, error prone manual checking later.

“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.

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.

• 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.

For everyone to benefit,

• You, the vendor have to plan your releases and release with metronomic regularity; compare the delays with Vista to the 6 monthly releases of Ubuntu.
• Push small increments out to your customers. Perhaps every month,
  or every 3 months. This will depend on how big your application is, and
  how much you can automate the upgrade (at least for desktop apps)
• Get out of the 1.0 – 2.0 mindset. Let your product grow organically, and let your customers see it doing so.

Frequent small releases are a great way to make your product seem really alive – it has a heartbeat. It also gets you a regular dose of the key ingredient – feedback. Regular feedback
allows us to provide regular, iterative enhancements, not big bang
feature drops. When we drive from A to B, we don’t point the car and
accelerate, we make small iterative corrections to the direction and
speed of the car based on the feedback we get from our senses; software
is very similar in this regard.

SaaS has been around for a while, but it’s only recently that I’ve
seen SaaS really getting talked about in Desktop application circles.
Hopefully, we’ll see the adoption of this approach across Shareware and
larger enterprise apps.