The modern world is made of lots of moving parts. Nothing is orchestrated, there is no grand plan, but they come together to make the world we live in.

It is this ‘complexity’ that makes predicting anything impossible. It also makes predicting solutions to the worlds problems, be it economic, crime, world hunger or even how our business will run in 10 years time impossible. We turn to our leaders and experts for guidance, to steer us in the right direction, but it turns out that for long term goals, they have as much influence as the rest of us. Where the leaders and the experts go excel at is leading in the short an medium term. The reason for this is that their expertise can only go so far before entropy kicks in and it just makes it impossible to be right. So how should you solve problems, in incremental steps.

Surprisingly, this method of solving problems has been around for billions of years. In Nature, its called Evolution.

In evolution, each incremental step starts off with a mutation (variation). If the mutation gives the organism an advantage, the organism lives and procreates spreading that mutation. If the mutation causes a disadvantage, it is more likely that the organism dies, and the mutation is no longer spread.

Karl Sims a computer graphics artist tried simulating evolution in a virtual world. From his videos, you can see that his virtual creatures started having traits that living creatures have. This just shows how well nature has used evolution to solve problems.

Types Of Complex Solutions

There are 3 types of solutions to complex problems.

Mount Fuji

photo credit:Reaching Out via photopin (license)

There is one, and only one perfect solution to the problem. As you improve, you get to the ultimate solution, any more effort and you are just going down hill.

Very few problems fall in this category, but when we solve a problem, we seem to think we have found the best way.

Rugged Landscape

photo credit:Sunny Mont Blanc via photopin (license)

Here, when you solve a problem, you have one solution of many possible solutions. Some better than others. It is very hard to find the perfect solution, but you need to keep trying to see if there is a more efficient, or better solution.

Dancing Mountain

Small Changes

So what constitutes a small change? Let me give you a real life example that I had. As part of the daily health check that I do for the company I work for. The health check steps are documented in a wiki page with checkboxes so you know which steps are executed as you go along.

Once of these steps was check if a file was transferred successfully to its destination. To do this, we would FTP to the remote host and see if the file was present every morning. This process didn’t take long. About 5 min each day. This was one task out of many as part of our health check that would take about an hour to accomplish if there was no issues. Over a day at times if there was. To save time with this check I wrote a python script that would show a web page (Using SimpleHTTPServer) of the remote directory to be viewed. The script took about 15 min to write. Now we have a visual indicator that is embedded in the wiki page (through iframes) to see if the file is present. This change alone saved 5 min. Yes, the script could be made better, a better solution would be to send an alert email or SMS etc if the file isn’t present or other countless improvements, but that is not the point.

This small change which saved 5 min was a first step. Other small improvements followed. Provided there are no issues, the health check is now down to 5-10 min. With issues, its is now rare that they would take a day or more. Most of the time its an hour or two to resolve the issues. We still have a long way to go, but we are on the journey.

The point is, that you start with something and build upon it and keep trying to improve it. Some things work, some don’t, but you won’t know until you try.

Galls Law

John Gall, an American paediatrician wrote a book “General systemantics : an essay on how systems work, and especially how they fail.”

In this book (Which I admit I haven’t read) there is one statement his is known for

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system

Here John Gall advocates building complex systems through evolution by starting with a simple system and building upon it. Pretty much how an Agile project should work.

 W. Edwards Deming

Now we come to the tail end of this post. Back in World War 2, while the men were fighting, the women would be the ones working in the factories. Building every day products and the machinery of war. With limited resources, the factories had to work smarter and harder to get reasonable productivity. Deming, through all this worked out a system to achieve this.

At the end of the war, all the men came back and the women were out and everything went back to the way it was. At least in America and the allied nations.

In Japan, they were just trying to re-build from after the War. Deming was brought over  the techniques that he developed during the war. The Japanese embraced this. None more than Toyota. Which is where we get the Toyota Production system and the start of Lean.

One of these techniques that Deming brought over was the PDCA cycle. Also known as the Deming Cycle.

• Plan your change and determine its success criteria
• Do your change
• Check that it meets the success criteria
• Act accordingly
  • If the success criteria is met, Yay complete.
  • If the success criteria is not met, the re-evaluate and plan the next step and repeat the cycle.

Conclusion

So as you can see, through independent means, many people have found that the evolutionary way to trial and error seems to be the best means to achieve the best solution to a problem. Be it nature, manufacturing or computer science.

I’d like to list my learning resources. Where I learn the most about software development, Devops and Testing.

I work during the day and my wife works at night. We have a 4yo son that I take care of in the evenings, so sometimes its hard to learn new things, especially when you need to dedicate a large block of time. To help counter act that, I like to learn by taking information in by various means. This includes video, audio and written content. I find that taking the same information in various means helps me understand and link the pieces together to a coherent thought. Usually I try to read, watch or listen to content on the train in the morning and evenings.

So, here are my sources.

Firstly, video.

Skills Matter This site is a British site for a company that hosts a number of talks and courses a week. They put up these talks for free. Its a good resource for finding the latest trends and perspectives.

SoftDevTube is the software development you tube, although not updated as often. It has varying topics, but isn’t updated often. Previous videos are very interesting though.

Confreaks.tv is mainly ruby based, but a majority of the topics are still relevant for any language. Again, this site isn’t updated that often.

DevOps Enterprise Summit puts up their videos of the conference. These are put up a few months after the conference, but there is quite a lot to keep you occupied for a while.

Youtube is also a great resource. Just search for topics, speakers, events etc and you can find content.

Podcasts

Test Talks Jo Colantonio hosts a podcast dedicated to testing and test automation. This podcast is mainly for web development, but I do find the concepts interesting.  I rarely miss an episode.

Software Engineering Radio I have been listening to this podcast for a very long time. Probably almost 10 years (The podcast is 10 years old, and I started listening quite early). The topics are timeless. I highly recommend listening from the beginning.

DevOps Cafe I have only recently started listening to this podcast, but it has been around since 2010. I’m trying to catch up from the first episode (currently at ep 11) but I have so far found it to be a great resource for DevOps theory from a high level.

Coder Radio Not as technical as you would expect, but I do find the topics interesting at times. I haven’t been listening for a while as I’ve been catching up on DevOps Cafe.

Meta-Cast I have only been listening to this podcast for about a  months to a year. The topics are interesting, but I tend to skip if I don’t find the title interesting.

Coding Blocks Another podcast where if I find the topic interesting, I will listen to.

Thats pretty much it for podcasts. There are a number of others, but these are my current regulars.

Web Sites

I tend not to read as much from Web Sites anymore. I flick through, but I tend to not read as much as I should. I use to read them quite a bit, but its getting harder to find the time.

DZone

This includes

• DZone Agile
• DZone Integration

I find DZone to be a good resource for blog posts of varying topic.

Reddit Programming Channel This is another resource that I find interesting at times. It is less policed than DZone, but still has great content.

Books

Instead of reading web sites, I’ve started reading more books. If a book is mentioned on a video or podcast, I’ll try to read it and learn. I tend to get my books through Amazon, through the kindle. Also Manning have Deals of the day where you can get up to 50% off. I tend to go for the ebooks as the dead tree versions cost quite a bit to ship to Australia. LeanPub is also another good source. Gojko Adzic, the Specification By Example guru has a number of books self published at LeanPub.

I also buy dead tree versions from the book depository and Abe Books. Abe Books is good to try first to see if there is a used version of the book available.

I have also found some books in op shops (Lean Thinking).

Other Learning Resource

Udemy – Lots of free courses (Found on OzBargain regularly) but like most Ozbargainers, I have yet to complete may courses.

The same with kindle books, they pop up every now and then on OzBargain.

There are many places to find learning materials. Most are free. What I tend to find is that a video might reference a book as a source of inspiration, which sometimes I will try to read, or a podcast will have a guest speaker which I will look to see if there are any videos available.  Sometimes you go down rabbit holes and learn the origins of where a theory came from. For example, with DevOps, it lead me to Lean, which lead me to the Toyota Production System – something completely unrelated to IT, its manufacturing but the content is still highly relevant. This then lead me to NUMMI which then lead me to changing culture etc. I find it fun going down and holes and learning along the way.  So have fun and let me know how you go.

 Where I work, we are starting to look into doing continuous integration. One thing that my manager wanted was a build traffic light, so I built one.It ended up being quite simple to build really. So here is how I built it.

Parts List

• IC Station Micro USB controlled 5v 4-Channel Relay Module
• 1 micro USB cable (to power and control the relay)
• 1 USB cable you are willing to cut the end off. This will supply power to the LED’s
• 1 Red LED
• 1 Amber led
• 1 green led
• Optionally, another colour LED as the relay module has 4 channels. For my implementation, I chose blue.
• Resistors. Check the specs of the LED’s but 100-150 ohm should do the trick. I used 150 Ohm.
• Wire – at least 2 different colours (red and black)
• Heat shrink
• A plastic case to house it in.
• A Windows PC. You could probably use Mac or Linux, but the software that comes wi the device is Windows only and it’s better to start with when playing around.
• Solder
• Electrical tape
• Multimeter

Tools required

• Soldering iron
• Needle nose pliers and a wire cutter if your pliers doesn’t have one.

First things first, connect up the relay to a PC. Install the software and try to get the relay module to turn on and off. You will need to make sure that the relay module connects up to a com port lower than 5, if your port is recognized as higher, then try changing sub ports.
Also, you will need to install the driver. This should automatically install if your windows pic is connected to the Internet.

Using the software, you should be able to turn individual relays on and off.
  
Once you have the relay module working, the next step is to build the circuit.

The reason for the resistors is so that the full current does not short out the circuit and blow the power or the diodes.

A little bit of background. An LED will only light up when you when the current flows in a certain direction. So if you have the positive and negative e wrong way around, the LED will not light up.

Usually, the anode is the side where the wire is a little longer, but the best method is to hook up the led to a battery and see which direction causes the LED to light up.

Start off by soldering one of the resistors to the Anode of the LED.  You may want to clip the anode wire a little so it doesn’t look too long.. Repeat this for all the remaining LEDs.

Next, solder the wires to the Resistors and the LED cathode. I prefer to use a different color wire for each anode. For example, to match the colours of the LED. For the cathode (negative) side I used the traditional black.

Put heat shrink around each join
Each switch is one of the relay switches.

Below you can see one of the LED’s. It has the heat shrink around the joint. I have also used electrical tape to beaten up the wireing.  

Once you have the LEDs wired up, the next step is to wire up the power supply to light up the LEDs. I’ve chosen to power my LEDs through another USB port. The USB port provides 5V DC power which is enough to light them up.

First thing you have to do is cut off the end of a USB cable, You want to keep the Standard A side, that is the rectangular side,this will plug into the computer obviously.

There are 4 pins to the USB port, the outer pins are the power, the inner pins are the data.

To find out which pin is which to the wires, I used a multimeter. I just checked for resistance between the wire and the pin, if the resistance is zero, then you have a short and the wire matches the pin.

Cut away the data wires, you do not need them. Finally, wire up the USB port to the LEDs using the above circuit diagram as a guide

Test your traffic light with the software found on the USB Relays web site above and place into a plastic container to keep the circuit isolated.

You should now have a basic working traffic light.

You will just need to create traffic light stand, in my case I kept the lights raw and just taped them to a post at the office.

The traffic light should only draw 33mA with a 150 ohm resistor.

Find an old PC and hook up your traffic light. 

The next step is to write software that will control the traffic light. To get the basics under python, there is an example already supplied on the USB Relay site as well, but I chose Java.

Java natively does not provide access to the serial ports, so I had to choose a library. I chose Java Simple Serial Connector. It provided a simpl interface that allowed me to communicate with the relay easily.  To send each bit, I sent the HEX value for the byte i.e. 01 for bit 1, 02 for bit 2, 04 for bit 3 and 08 for bit 4. 

If you want to do a combination of lights, for example bit 1 and 2, just send 03.  It’s fairly simple once you play around with a basic program. 

Changing lights is sub second speed, so you can I effects like rotating the lights before a change. The relay will also make a nice audible like a wheel of fortune wheel.

Unfortunately, due to my company owning the code to the traffic light even though I wrote it, I cannot include it here, but if you are using this for a build traffic light, you should be able to figure it out fairly easily.
 

If you end up building your own traffic light or have any issues, let me know in the comments or send me an email. My email is found in the About page. 

I have recently finished reading Tim Harford’s “Adapt: Why Success Always Begins With Failure”.

I found the book very interesting. So good in fact that I have bought a physical copy to compliment my electronic version and be able to loan out to my mangers.

In the beginning, Tim talks about the disruptors and how although ostracised by their leaders, how they overcame and accomplished their goals, even though they were against all odds. Their reward, punishment. In Peter Palchinsky’s case he was executed.

Peter was a mining engineer during the early soviet era.  He spoke out against large soviet projects, saying that they were not correct. Such as in the case of the Magnitogorsk steel city, Dnieper Hydroelectric Power Station.

For this, he was executed, but he was a brilliant engineer and he came up with 3 principles which tie in to Innovation and DevOps culture in my opinion.

  Peter Palchinsky’s Principles

• first : seek out new ideas and try new thing.
• second : when trying something new, do it at a scale that is survivable
• third : seek feedback and learn from your mistakes.

I’ve started re-learning how to play a guitar again after a more than 10 year hiatus. It’s a little difficult. I’m not starting with something simple, I’m going for complex. I’m re-learning to play ‘Classical Gas’ by Mason Williams. 

I started by learning the first bar. Just 4 notes. Repeated that a few times then went to the next bar. Then I put the 2 bars together and played then a few times. I repeated this for the 3rd and 4th bars. Iteratively learning and reinforcing what I previously learned. 

I feel the same should be done with development. Build the first bit of functionality. Iterate over and refactor till you are happy. Build the second bit of functionality.  Iterate over that. Review any lessons learned from the previous bit and then move on. Keep continuously improving and when you are finished you should have an app very well built. I know. I know. Easier said than done, but the simple fact that you are trying to improve means you are improving. Eventually you should get to the point where the review you do after writing new functionality should be a cursory glance every now and then and can should take the form of automated tests (but not too early)

You should be confident your code runs well, reads well and be proud. 

Well… That is the dream at least.  

A little while ago, I had a discussion with one of my colleges with regards to documentation. His argument was that the best documentation was the code. My argument was contrary to that.

I thought I would discuss my thoughts here.

Te get things started, lets say you have the below code…

package com.beanietech.fizzbuzz;

public class FizzBuzz {

    /*
     Extra fizz for your buzz!
     */
    public static int fizzbuzz(int fizz, int buzz) {
        while (buzz != 0) {
            int awesome = (fizz & buzz);

            fizz = fizz ^ buzz;

            buzz = awesome << 1;
        }
        return fizz;
    }

}

I’ve changed the variable names to make it a little obscure, but given its only half a dozen lines of code, can you tell me in 10 seconds what it does?

My guess is that you can’t. I couldn’t.

I could write a word document that describes the functionality, it could say…

Given 2 numbers, the two numbers are multiplied together and the result is returned.

Ah, now you say, I know what it does!

Are you sure? Word documents can be incorrect or out of date. You cannot rely on them.

So what is next?

This is where my argument comes in. My thoughts are that the best documentation is the tests. Not the code, and not the description of what the document does.

So lets write a test.

import com.beanietech.fizzbuzz.FizzBuzz;
import org.junit.After;
import org.junit.AfterClass;
import static org.junit.Assert.assertEquals;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;

/**
 *
 * @author hpaff
 */
public class TestFizzBuzz {
    
    public FizzBuzz fizzBuzz;
    
    
    public TestFizzBuzz() {
    }
    
    @BeforeClass
    public static void setUpClass() {
    }
    
    @AfterClass
    public static void tearDownClass() {
    }
    
    @Before
    public void setUp() {
        //fizzBuzz = new FizzBuzz();
    }
    
    @After
    public void tearDown() {
    }

    
    
     @Test
     public void testFizzBuzz1() {
         assertEquals(4,FizzBuzz.fizzbuzz(1, 1) );
     }
     
     @Test
     public void testFizzBuzz2() {
        assertEquals(4,FizzBuzz.fizzbuzz(2, 2));
     }
     
     @Test
     public void testFizzBuzz3() {
           assertEquals(6,FizzBuzz.fizzbuzz(3, 3));
     }
     @Test
     public void testFizzBuzz4() {
           assertEquals(8,FizzBuzz.fizzbuzz(4, 4));
     }

}

As you can see, the tests clearly show what the functionality is.

When we run it, We get confirmation.

So now we know that the method adds two numbers.

Now I hear you say, “Tests are not very user friendly, how is a business person suppose to understand this?”

Well, this is where my second part of this discussion comes in.

There is an open source project called Concordion that can help with this.

Concordion allows you to specify the functionality as examples into an HTML document. It uses the “<span>” tag to mark out sections of the document to be executed.

So, for our little example, our HTML specification would be:

<!DOCTYPE html>
<!--
To change this license header, choose License Headers in Project Properties.
To change this template file, choose Tools | Templates
and open the template in the editor.
-->
<html xmlns:concordion="http://www.concordion.org/2007/concordion">
    <head>
        <title>Test FizzBuzz Concordion</title>
    </head>
    <body>
        <h1>Test FizzBuzz with Concordion</h1>
        
        <p>If the Fizz is <span concordion:set="#fizz">1</span> and the Buzz is <span concordion:set="#buzz">1</span> then the FizzBuzz should be <span concordion:assertEquals="fizzBuzz(#fizz, #buzz)">2</span></p>
        
        <p>If the Fizz is <span concordion:set="#fizz">2</span> and the Buzz is <span concordion:set="#buzz">2</span> then the FizzBuzz should be <span concordion:assertEquals="fizzBuzz(#fizz, #buzz)">4</span></p>
        
        <p>If the Fizz is <span concordion:set="#fizz">3</span> and the Buzz is <span concordion:set="#buzz">3</span> then the FizzBuzz should be <span concordion:assertEquals="fizzBuzz(#fizz, #buzz)">6</span></p>

        <p>If the Fizz is <span concordion:set="#fizz">4</span> and the Buzz is <span concordion:set="#buzz">4</span> then the FizzBuzz should be <span concordion:assertEquals="fizzBuzz(#fizz, #buzz)">8</span></p>

    </body>
</html>

Which renders to:

Test FizzBuzz with Concordion

If the Fizz is 1 and the Buzz is 1 then the FizzBuzz should be 2

If the Fizz is 2 and the Buzz is 2 then the FizzBuzz should be 4

If the Fizz is 3 and the Buzz is 3 then the FizzBuzz should be 6

If the Fizz is 4 and the Buzz is 4 then the FizzBuzz should be 8

All very readable.

The next step is to add a fixture.  A fixture is a bit of code that links the HTML page to the system you are trying to test.

For this simple execution, the fixture is:

import static com.beanietech.fizzbuzz.FizzBuzz.fizzbuzz;
import org.concordion.integration.junit4.ConcordionRunner;
import org.junit.runner.RunWith;

@RunWith(ConcordionRunner.class)
public class FizzBuzzFixture {
   
  public int fizzBuzz(int fizz, int buzz){
      return fizzbuzz(fizz, buzz);
  }

}

Now, when we execute the fixture, we get:

As you can seem the results are green. If for example, we got something wrong, we would get.

So, if we ties this into a continuous integration suite such as Jenkins or Bamboo, we should always have up to date documentation that has been verified and human readable.

Now, if we need to add more tests, we no longer need to write code for this particular scenario. Why? Because we have decoupled “What we are testing” from “How we are testing“.

The fixture controls how we test the method, but the HTML page controls what we are testing. So, to add more tests, provided we haven’t changed any functionality, we just need to modify the HTML page.

Finally, in this example I used Concordion. But there are other tools out there such as Fitnesse which is wiki based, Cucumber and JBehave which is Text file based and numerous others.

Concordion, like Fitnesse is another Specification By Example tool which I like because of its free form structure.

Concordion uses HTML as its syntax to write specifications. With the HTML, it uses the <span> tag to specify commands. Just like Fitnesse, fixtures are required to interpret the specification and execute the tests. Tests are written in Java using ether JUnit or TestNG. Other languages are supported, but I haven’t tried them.

The basic functions of Concordion are:

Assert Equals : To assert whether a value is equal and return true or false.

Set : Sets a variables value.

Execute : Execute an instruction with a result. The result can be void.

Execute On A Table : Executes the same behaviour across a row on a table. This is good for verifying multiple input tests.

Verify Rows : Allows you to verify the results when multiple values are returned. For example when returning the results form a database query.

When you run a test, Concordion returns HTML which has been marked up with the test results.

Advantages

The advantages of using Concordion over Word documents (and even in some cases fitnesse) are

• It uses HTML. Be careful though using WYSIWYG HTML editors. The HTML generated may be complex and it might be easier to just hand code the HTML yourself.
• Concordion is simple to understand and implement.
• Just like Fitnesse, it is easy to see when your document is up to date and that the examples are correct.
• Integrates well with Jenkins. I had no troubles incorporating within Jenkins and just used the HTML report plugin to incorporate the results.

Disadvantages

Again, like Fitnesse, there are a number of disadvantages of using Concordion over a Word Document.

• Requires coding compared to a word document, but then again, the purpose of Concordion is different.
• There is no version control built in, but saying that, you can tie the HTML with your source code and check in at the same location. That is what I have done.
• Again, just like HTML (Well, it is actually…) images and attachments need to be stored in separate files.

I like Concordion for its simplicity. I haven’t tried Concordion with message formats such as XML, but I’m assuming that the same caveat with Fitnesse where you need to decode the XML still applies.

Saying that, I do have some ideas about using the test data builder pattern to generate my XML message based on a table of inputs.

Maybe one day I’ll get around to doing it.

Let me know in the comments which you prefer, Concordion or Fitnesse and especially if you are using these in any SOA/Integration space.

When I was much younger, I use to play the guitar. For my first guitar, I had bought it at an auction at a market. The pickups didn’t work, the nut was missing, no strings, but I was determined to learn. So I went to the nearest guitar shop that did repairs and took it to them.

Several parts later, I had a working monster, and it was a monster, but it got me started.

Not long after, I got a new guitar. Not much better, it was the cheapest one I could get. It had only 21 frets, and the amp I got was a cheap and nasty from Tandy at the time. What do you expect, I was a poor student at the time. That was when I really learned to play, and so I practiced every chance I got.

One thing I heard or read somewhere at the time that has stuck in my mind is that having a very expensive guitar like the one your favourite guitarist plays does not make a bad guitarist good, they will sound bad regardless, but a great guitarist can make a box and strings sound great and a good guitar sound amazing.

So where am I getting at, well… In my experience, companies go and fork out hundreds of thousands to even millions of dollars for tools or frameworks to help with their corporate development thinking it will save them lots of money, make things easier and or get them there sooner and a lot of the time, these projects generally fail, cost a lot more money, take forever to get off the ground as they wait for approval to spend the funds or end up not being what was envisioned in the first place.

In these circumstances, the time to practice, the time to learn the fundamentals of what this new product is meant to make easier, the time to iterate over your procedures to learn what is the best way to implement, the time to become a good player has not been put in.

My advice is to start learning the fundamentals today. Use open source software (it may surprise you), build your own stuff, cobble together scripts, read, learn, practice. Just workout your own sound. Learn to play with that box and strings and make it sound good so that when you get your new shiny tool, framework etc – you will just sound amazing!

As mentioned in my previous post, Fitnesse is a product used to describe specifications using the Acceptance Test Driven Devlopment or Behaviour Driven Development methodology.

Fitnesse was created by Robert C. Martin (Uncle Bob) about 10 years ago and originally was based on the FIT language created by Ward Cunningham.

Fitnesse uses a wiki to write your specifications and fixtures written in multiple languages, but originally in Java.

Fit provides the ability to create :

Column fixtures : Where the rows represent inputs and expected outputs

Rows Fixtures : Testing queries that return an exact set of values (Ordered independantly)

Action Fixture : Allows you to write a script that emulates a series of events.

Comment Tables : Allows tabular comments that are not executed as tests.

Slim, the other language used by Fitnesse provides a lot more functionality.

Decision Table : Supplies the inputs and outputs for decisions.

Dynamic Decision Table : Same as the decision table, but passes column headers as parameters for the fixture.

Query Table : Supplies the results of the query.

Subset Query Table : Supplies a subset of the results.

Ordered Query Table : Supplies the expected result of a query in a particular order.

Script Table : Allows scripting a series of actions and checks.

Table Table : Allows you to write a fixture that arbitrarily executes as specified.

Import : Add path to the fixture search path.

Comment : Add a comment

Scenario Table : A table that can be called from other tables.

Library Table : A Table that installs fixtures available to all test pages.

Define Table Type : A helper table that defines the default table for named fixtures.

Advantages

There are a number of advantages of using Fitness over using word for your specification documentation. These include…

• Built in Version Control. You do not need to add your specifications to a version control system. Adding is supported but not required.
• Its easy to see when your document is up to date. You simply run the test. If all is green, all is good.
• The wiki is rendered to HTML. So you can export to to HTML documents or Rich Text format for those who would like to use Word.
• You can use CSS to format your pages. So you can have everything company specific, team specific or however you like.
• Built in User Access Control, so only registered users can modify the documentation.
• There are a lot of plugins that can extend the functionality of Fitnesse.

Disadvantages

Consequently, there are a number of disadvantages of using Fitnesse over Word.

• Fitnesse requires coding to get the background tests done. None required by Word (given it can’t execute tests anyway).
• Adds another layer of complexity, but saying that, I would say the benefits are greater.
• When using XML messages as sample data, they are encoded to be visible within the wiki format. Therefore before you use them in your fixtures, you need to decode (ie change the &lt; &amp; etc characters) to get the original XML.
• You also get formatting issues with using XML. ie, leading and trailing spaces that needs to be fixed by the fixture.
• Editing the wiki text can be quite difficult if you have exotic formatting. I had some issues getting tables looking like they would in word where you have merged cells etc.
• Not everyone is comfortable with a wiki, epecially non technical people. This was the biggest argument I had with my team about Fitnesse. I don’t think it is founded. Mind you, we had the same argument about Mardown.
• Just like a wiki/HTML page, embedded images and attachments are stored in separate files.
• You are not able to make the document as pretty as a word document. But then again, that isn’t the purpose.

Fitnesse is a very powerful tool and I think using it for specifications is very advantageous especially if you are using free form documents for your specs.  If your organisation is  adverse to change, this may be one way to bring Specification By Example tools in while keeping a similar document format to your current word documents.

Getting started with Fitnesse is easy. The documentation is very well written and can get you started very quickly.

I would very much like to hear if anyone else is using Fitnesse, especially in the SOA/Integration space and how you document your message formats. Please let me know in the comments.