What makes a successful software development?

I’ve been thinking recently about what makes a software project successful. Of course this depends on what you measure success by and where your team is starting from in terms of previous success and skills, however I’ve found that a minimum set of basic practices can make a big difference in the outcome of your project. This is purely my own opinion based on personal experiences, not all of the following will work for everyone but I hope the general principles are useful no matter what your circumstance. They are in no particular order.

1. Maintain a backlog

Keep a single, prioritized list of outstanding tasks. This must be loved, maintained and groomed, preferably by a single person, preferably the product owner. This list enables self organising teams, empowers developers to take control of and responsibility for the work they do. As it is a single list containing all types of tasks – bugs, improvements, documentation jobs – the team has a single location for all outstanding work. As it is prioritised any team member can easily find the next most important thing to do. As it is maintained the team has confidence that the list is up to date and correct.

2. Technical practices

Any software development hinges on the capabilities of the developers. Bad developers can kill a project, good developers can save it. You absolutely cannot cut corners on technical practices and training. A development team should have an ongoing commitment to training, adapting to the needs of the project but also addressing regular practice of foundation skills. The most fundamental of these is Test Driven Development (TDD). A developer with a good grounding in TDD and a basic knowledge of a language can very quickly and relatively easily create functional, proven software that is easily extensible, easily maintained and easily understood. This is the fastest and most reliable way to become a reliable and effective team member.

I have also grown to value ad-hoc pairing to encourage knowledge sharing and increase the quality of the software produced. Two heads are always better than one, from design and implementation to testing and definition, although pairing is hard partly because it is difficult to get over the counter-intuitive hump that pairing actually makes you go faster in the long run. Hand in hand with TDD goes simple design, small changes and the SOLID design principles. It is fairly straight forward to create software that adheres to the SOLID principles when using TDD.

3. Daily standup

You can substitute this section title with “morning sync”, “scrum”, “water cooler catch up”. There are many ways to achieve the same affect, the critical part is to create a means by which the team regularly and consistently talk to each other so that everyone knows what the others are doing, who to go to for help and if anyone is blocked. The standup should be quick (5 mins), concise (no rambling) and small. Teams of 8 or more are pushing it and the important points are more likely to get lost amongst noise. It is the job of the scrum master (or coach, or team leader) to make sure the standup achieves its intention and to pursue any blocking points the team raises and remove the blockage as quickly as possible.

The benefits are that problems are raised as soon as they happen, are visible to all team members and a self organising team can optimize their activities based on the daily update. This makes the team responsive, adaptable and highly focused on delivering business value.

4. Project board

Provide a visible, accessible project board that the team can use, change and update. This is best if it is physical but if that is not possible then a virtual representation can be made to work. The project board should be a focus of the daily standup and the team members will likely make use of it several times a day. Task progression can be tracked here as well as blocking issues, milestones, bug counts and any other information relevant to the project. Other terms for these boards are information radiator, kanban board or scrum board.

What I’ve Learnt From The Game Of Life Kata

The Game of Life kata is all about implementing the standard rules of Conway’s Life to produce a new generation of cells from a previous generation. Here is what I have learnt.

1. Where You Start From Matters

The Game of Life kata has many starting points, here are two possible choices:

• Represent the ‘board’ with a two dimensional array
• Represent the ‘board’ as a set of live cell coordinates

This kata is certainly achievable wherever you start from but you may have a quite different solution and find differing challenges along the way. It shows that it is worth repeating katas and considering how you might approach the problem in an alternative way.

2. New TDD Tcchnique – Guiding Tests

I used this technique without realising it about a month ago, it was kind of unintentional and I didn’t recognise it as a repeatable pattern until I saw Kent Beck using the same technique in his TDD series on pragprog.com, specifically in Episode 3. This is a great way breaking down a complex problem into manageable chunks whilst still keeping a view of the required end result. The idea is during a standard TDD session you might come across a chunk of functionality you need to write to fulfil a test – you realise this chunk is quite large and perhaps it makes you uncomfortable to be writing all this code in one go for a single test. Keep the test you’re working on, we’ll call it the guiding test; either comment it out or leave it in but be aware it will continue to cause a red cycle. Then identify a smaller piece of work that will achieve some part of the larger work you are trying to achieve, write a test for this as normal, implement it and repeat until you have achieved enough small pieces to make the large piece writable.

Now you have a choice. You can leave in all the tests that allowed you to achieve your guiding test, probably leaving a number of methods public which might not be used for other purposes, or you can remove the intermediary tests and hide the methods they tested away again. Which way you go with this depends on a lot of things, personal preference, complexity of the code, whether the intermediary tests exposed useful interfaces on the object under test.

 

Autotest-a-like for bash

I’ve been programming a bit of Ruby and Python in the past few months and one of the things I’ve found most useful is autotest. This is a Ruby tool that detects when you’ve changed a test file or source file and runs the tests for you. This is triggered upon save so you don’t have to do anything that edit and save, it’s that easy. Python has sniffer which is also great and does pretty much the same thing.

I mostly program in C++ at work and would love to have a similar tool. Unfortunately much of the auto detection about what tests to rerun is possible thanks to the dynamic nature of these languages, however the idea of running a command when some files change could still be applied to my situation so I wrote the following shell script.

It’s really simple, all it does is take three arguments; a delay in seconds between checking for changes, a command (quote it if you have a compound or multi-word command) and a list of directories within which to check for changed files since the last time the command was run. The command will be run at the start of the script is run and is then only triggered by file changes.

You can find the script on github here or you can be lazy and see the source code for the current version below – but be warned this might be out of date with the github code!

#!/bin/bash

trap ctrl_c INT

ctrl_c() {
    rm ${watchFile}
    exit 0
}

run_command() {
    touch -t `date +%m%d%H%M.%S` ${watchFile};
    echo "Running '${command}'";
    eval ${command}
}

usage() {
    echo "Usage: watchAndRun.sh <check period in seconds> <command to run on change> <list of directories to watch for changes>";
    echo " e.g. watchAndRun.sh 5 \"echo 'yes'\" src . .."
    exit 1;
}

# Arg one is delay in seconds between checking for changes
# Arg two is command to run on change detected
# Arg three* is list of directories to watch for changes

if [ "$1" == "" -o "$2" == "" -o "$3" == "" ]; then
    usage
fi

delay=$1
command="$2"
directory_list=

shift; shift; # Remove first two args to leave $@ containing only directories
while (( "$#" )); do
    directory_list="${directory_list} $1"
    shift
done

parentPID=`ps -fp $$ | tail -1 | awk '{print $3}'`
watchFile=/tmp/watch${parentPID}

while [ 1 ]; do

    if [ ! -e ${watchFile} ]; then
        echo "Created watch timestamp file '${watchFile}'"
        run_command
        echo "Waiting for changes..."
    fi

    if [ `find ${directory_list} -type f -newer ${watchFile} | wc -l` != "0" ]; then
        run_command
        echo "Waiting for changes..."
    fi

    # echo "Sleeping for $delay seconds"
    sleep ${delay}
done

Idea For A Team Dojo – Sim City

I’ve been involved in a lot of coding dojos recently, where developers pair up and attempt a set kata, e.g. prime numbers, roman numerals, bowling game. I thought it might be interesting to attempt a team dojo where the developers still pair off but everyone is working on part of a greater whole. This would enable the developers to experience evolving design, engage in team collaboration practice outside of a single pair and participate in a much larger software development exercise than would usually be done as a kata. Of course the motives for doing this are quite different to that of a kata, as such this is not intended to replace katas practice, rather the idea stands as a parallel practice on it’s own.

The session goes as follows:

- Introduce the participants to the team dojo idea.

- Explain the role of product owner and display the requirements as above in a very visible place, i.e. projector screen, white board.

- Ask the team members to pair up then each takes a turn to pick which part of the project they will work on from a lucky dip hat.

- Give the team 5-10 minutes to have a group discussion, then the pairs must start developing their component.

- The teams are allowed to communicate freely, use whiteboards and whatever materials they wish but the emphasis should be on evolving the design and close collaboration between pairs as development progresses.

- The pairs may talk to the product owner at any point about any aspect of the requirements. The product owner should endeavour to give a decisive, concise and clear statement to the developers questions to quickly unblock the developers from progressing.

- As the task is rather large the session may be continued on multiple days, one suggestion might be to have a weekly 2 hour session for 8 weeks.

 

One idea for this might go something like this:

1. I am the product owner, I provide the requirements and clarification.

2. My requirements are:

  a. I want a game very similar to the classic Sim City (http://en.wikipedia.org/wiki/SimCity)

  b. It should be turn based and single player.

  c. The player starts with 100 wealth.

  d. Each turn the player can buy and place a single unit or pass, causing the turn to expire immediately.

  e. The available unit types are with cost in brackets:

      i. House (10)

     ii. Shop (20)

    iii. Office (30)

  f. At the end of each turn the following rules are applied:

      i. The city population increases by one for each house on the map

     ii. The city wealth increases by one for each person in the population.

    iii. The city happiness increases by one for house that has a shop and an office within 1km.

    iv. The city happiness decreases by one for house that does not have a shop and an office within 5km.

  g. Disasters can occur at random intervals.

  h. The game can be saved and loaded.

  i. There should be a graphical interface which runs under windows as a minimum.

  j. The development should be done in Java using TDD.

3. The available areas to work on are:

  a. GUI

  b. Save/load

  c. Game model

Does TDD foster short term thinking?

I’ve noticed recently an improvement in my ability to manage short term tasks, not just when programming but in other aspects of my life too. I credit my TDD practice at work with infecting my thought processes and behavioural patterns that enable me to be more effective, to choose what must be done now and what can be left till later.

I have also been considering that perhaps TDD has a dark side; it keeps you focused on the here and now, the most valuable current task and encourages minimising distractions by writing them down as an aside, to clear the mind from the mental junk of things that do not need to be done now. You invest faith in the idea that a full solution will evolve from the pieces that TDD guides you to create. This is all very reasonable and works well in practice however I wonder if my long term planning skills are wasting away… I no longer need them, nor think of a long term plan as I used to. A long term plan is now simply a series of probabilities of events occurring with exponentially decreasing likelihood over time. How can anyone care about a long term plan with that outlook? How can I feel invested in the future of such a plan when I know there’s a really high chance that it will not turn out as expected? The longer the plan, the greater the divergence between the expectation and the real final outcome, and the lower the attachment to it succeeding.

I suppose this may be where the non functional goals of the plan come into play beyond the final achievement. What are the ethical and moral goals of this project? What can I gain personally from participating, monetary reward, recognition, experience and training? Even so, should I be concerned that my long term planning skills are seemingly degrading through lack of use, if effective solutions evolve so readily then what do I need these skills for? Something is nagging at the back of my brain and I can’t quite grasp the impact…

Pair Programming – What’s It All About?

Of all the practices associated with agile development the one that  developers appear to fear the most is pair programming. This is the practice of literally writing code with a partner. I don’t mean someone to look over your shoulder or who reviews your code after you’ve written it but a partner where all code writing responsibilities are shared. Both partners spend equal time at the keyboard, ideally the desk, chairs and monitor are orientated to give an equal viewing position, the typing role is changed at frequent intervals and both partners constantly engage with each other. An ongoing review process occurs when you have this situation.

Of course there’s no need to be afraid but it is understandable. The practice is quite alien to most developers who are more used to being assigned tasks and working alone, only consulting they’re colleagues when they have a problem.

Advantages of pairing

* Spelling and syntax errors are picked up much earlier when pairing, saving time in the compilation loop – it all adds up.
* Knowledge is shared about the software you are writing. One source of understanding is a bad thing, what if that person falls ill or leaves the company?
* Pairs learn from each other, tools, practices, language knowledge. This is an easy way to share this information and it’s nearly always a two way exchange.
* Constant verification of your evolving design. This works really well when combined with TDD which forces you to think carefully about your code design but only so much as is needed by the requirements you are attempting to fulfill.

I’ve been fortunate recently at work in that I have been able to spend a good proportion of my time pairing. Thanks to this I feel the code we produced was of a higher quality than would otherwise have been possible. I now share at least one of my colleagues feelings of discomfort when writing code without a pair and try to pair whenever practically possible.

I observed an interesting parallel last night while watching Denmark play Indonesia in the Olympic Bronze medal mixed doubles badminton match. The Danish pair ruled the game throughout while technically the players should not have been that dissimilar. The biggest difference and one which was constantly talked about by the commentators was that the Danish pair were in continuous communication with each other. They dominated in part due to their team work and this was due to great communication. Likewise, to be a great pair to program with you have to communicate, what you are thinking has to be said out loud otherwise you are simply two people programming rather than a pair.

Jon Skeet writes an IoC container in C# in 15 minutes

In this YouTube video/TekPub outtake Jon Skeet writes a minimal IoC container from scratch in 15 minutes. Whilst that in itself is impressive what I gained the most from watching this video was a great demonstration of combining an array of techniques:

* Reflection

Used to find an ‘Instance’ field, constructors methods and arguments and invoke the constructors themselves.

* Generics

Used with Injector.Bind to supply instances of types to use for injection. One version of Bind uses two generic types, the first to specify the interface to bind to and the second type which Bind requires must provide an Instance field to get the singleton instance of the  type.

* Linq

Used to avoid and simplify loops. Jon start writing a for loop at one point, quickly retracting it and rewriting the statement with a simple Linq ‘Select()’ to resolve all the dependencies of the constructor argument.

* Lambdas

Passed to Linq statements, such as ‘Select()’ and populating a map of functions to bind the type to.

All in all a fascinating look at how an IoC container might be written (should you ever need to write your own!) with lots of other C#/dynamic langauge goodness packed into a mere 15 minutes.

Roman Numerals Kata continued – Cucumber!

I decided to use Cucumber for my next iteration of the Roman Numerals Kata. This worked great, it introduced me to BDD with Cucumber which allows for a much more human readable specification to be written. For example this is my first test:

Scenario: The number 1
 Given I have supplied the arabic number 1
 When I ask for the roman numerals
 Then the result should be I

It also led me to think about the problem slightly differently due to the Given/When/Then structure of the test specs. I ended up looking into extending the Ruby Integer class to give it a ‘to_roman’ method rather than creating a utility class ‘RomanNumerals’ to do the same job. This allowed me to explore the Ruby feature of class extension – because all Ruby classes are open to extensibility even after they have been defined. This is an awesomely powerful feature meaning I could now do this:

27.to_roman  == "XXVII"

Simply by supplying a definition of the to_roman method:

class Integer
  def to_roman
    ... convert the number represented by 'self'
  end
end

This is so much more natural than the alternative utility class I had produced before:

numerals = RomanNumerals.new
numerals.to_roman( 27 ) == "XXVII"

Another feature of Cucumber is the Scenario Outline. This allows you to define a scenario template that can then be fed with one or more sets of example data. This helps greatly to keep your feature specification clean and concise. For instance I reduced my scenario set of the Roman Numerals Kata from about 10 scenarios to 1 scenario outline that looked like this:

Scenario Outline: Converting an arabic number
 Given I have a roman numerals converter
 When I supply the arabic number <number>
 Then the result should be <numerals>
 Examples:
   | number | numerals |
   |   1    |    I     |
   |   2    |   II     |
   |   3    |  III     |
   |   4    |   IV     |
   |   5    |    V     |
   |   9    |   IX     |
   |  10    |    X     |
   |  40    |   XL     |
   |  50    |    L     |
   |  90    |   XC     |
   |  100   |    C     |

The  items in angle brackets are essentially variable names and the examples table has one row per scenario to create,

Roman Numerals Kata, Ruby and RSpec

So I’ve been doing the Roman Numerals kata for nearly a week now – bit bored of it but I’ll swap out on Monday. I’ve been doing it in Ruby, started with test/unit but quickly changed to RSpec to learn the BDD approach.

From what I’ve experienced so far I really like BDD. It feels like the an evolutionary step on from TDD and RSpec in Ruby in particular is very smoothly put together and scans superbly in the code. Here’s a quick example of an RSpec spec:

describe "Roman Numerals Converter" do
  before :each do
    @numerals = RomanNumerals.new
  end
  context "special symbols" do
    it "converts 1 to I" do
      @numerals.toRoman( 1 ).should eq "I"
    end
    it "converts 5 to V" do
      @numerals.toRoman( 5 ).should eq "V"
    end
  end
end

I’ve uploaded my full Ruby/RSpec solution to GitHub here

Might try combining my next attempt with Cucumber for acceptance tests might keep it interesting until Monday…

Ruby development essentials

Here’s a quick list of the tools I’m discovering I need or find useful for Ruby development:

• Vim!
  • Vim autocomplete for Ruby - http://www.cuberick.com/2008/10/ruby-autocomplete-in-vim.html
• JRuby http://jruby.org/
  • A Ruby interpreter implementation with easy Java interaction, simply “require ‘java’” at the top of your Ruby script and run the script with ‘jruby’ instead or ‘ruby’
• Ruby test/unit http://ruby-doc.org/stdlib-1.9.3/libdoc/test/unit/rdoc/Test/Unit.html
• RSpec http://rspec.info/
  • Install in JRuby with ‘jruby -S gem install rspec’
  • Use in JRuby with ‘jruby -S rspec <spec file>’