Executable specifications are scenarios created by developers, testers and stakeholders working in collaboration that check the behaviour of a system every time code is committed. For more information and a podcast about Executable specifications check out this Hanselminutes episode ‘Executable Specifications with Gojko Adzic, Jonas Bandi and Aslak Hellesoy’.

The need for change

A few months ago after joining the team, there was a lot confusion how a previous project worked.

Stakeholders weren’t sure what functionality had been implemented, testers weren’t sure if everything had been tested and developers didn’t want to go anywhere near the code.

While there was a wiki no one was sure if was 100% accurate which meant it could do more harm than good because it could lead to false assumptions.

As a result of this the relationships between the groups had suffered.

Inspired by Dan North’s talk ‘How to sell BDD to the business’ I suggested using BDD (behavior driven development) and executable specifications to help prevent this happening in the future.

Testers and business owners were open to the idea but were skeptical to how valuable it would be.

So we decided to try it out on a small part of the project.

And it worked!

Working collaboratively we found relationships started to improve and there was a lot more trust between the groups.

At the end of the project stake holders, testers and developers agreed executable specifications were an excellent way to develop software and keen to adopt the approach for other projects.

So what sold executable specifications to the stakeholders, testers and developers?

• Scenarios that matched the business problems the stakeholders wanted to solve.

  This gave stakeholders confidence and lowered fear and resistance to change.

• Easy to read scenarios that matched the domain language the stakeholders were using.

  Stakeholders could relate to scenarios and therefore felt involved.

• Using scenarios to fill out the blanks.

  When the test team or developers found new scenarios they communicated using with stakeholders leaving out what should happen (the then step) for them to fill in.

• The use of tables.

  Tables allow the reader to visualise the data, reduce reputation and mean you don’t have to cram in lots of words.

  For example instead of having

  Scenario: Submitting form with invalid password displays error
    Given I am on the registration page
    When enter the password 'a'
    And submit the form
    Then I should see the message 'Passwords must be 8 to 16 characters long and include at least one capital letter, one lower case letter, and one number'
  

  and then repeating this for every permutation of invalid passwords, you can do this

  Scenario: Entering an invalid password displays error
    Given I am on the registration page
    When enter the password
      | a						|
  	| aaaaaaaa				|
      | AAAAAAAA				|
  	| aaaaAAAA				|
  	| 12345678				|
  	| 1234567A				|
  	| 1234567a				|
  	| 12345678aaaaaaaaA		|
    And submit the form
    Then I should see the message 'Passwords must be 8 to 16 characters long and include at least one capital letter, one lower case letter, and one number'
  

  We found this gave us valuable input from stakeholders and testers who were able to come up with scenarios much faster than before.

• Living documentation.

  Running tests to ensure the scenarios still reflected the behaviour of the system after every code change meant documentation was reliable and accurate.

The future

I’m pleased stakeholders, testers and developers have recognised the value of using BDD, scenarios and executable specifications.

By taking small steps, inspecting and adapting along the way, I hope that more projects I work on can adopt this approach.

One thing that has stuck in my head ever since has been her tip about getting people to draw a picture to represent how the sprint went.

The fact that it’s simple and easy to do is what makes it’s great.

She gave two examples, one was a group of people climbing half way up a very steep mountain and the other was a stretched limousine packed full of people without a driver.

This is definitely worth trying out in your retrospectives becuase it’s an excellent way to lighten the mood and get people contributing.

Whether you decide to keep it anonymous or not is up to you.

Here’s a drawing I’ve shown in a retrospective.

Since that day I’ve noticed that parenting shares many similarities with agile development.

I say this becuase from the moment a baby enters the world it’s all about inspect and adapt.

You’re forever analysing what they’re doing, checking they’re alright and planning and pirotising what to do next.

And while friends, parents and books give sound advice you have to look at your own context, every baby is different and so not every tip will work.

And this is when you’ll start doing mini retrospecives as parents. Every so often you’ll sit down with your partner discuss what went well, what didn’t and what to try next.

Using short feedback cycles you’ll soon work out what works best with the aim of developing sort form of structure.

You can’t do this waterfall becuase babies are unpredicatble and constantly changing.

As soon as you think you sussed it and plan too far ahead, the baby will go thru a growth spurt or learn something new and you’re back to square one before you know it.

It’s like a game of snakes and ladders, you’ll look at your partner and say this didn’t happen yesterday.

We’re four months in by working together and constantly sharing throughts and ideas we’re developing a routine which can cope with changes and… getting more sleep as each week passes!

As with any first project for a client I wanted to make a good impression and produce quality work and deliver on time.

Getting Started

When I started work on the project I noticed the previous developers had created a web site project rather than a web project.

Seeing this as a long term project, I converted the website solution into a web project. It was easy and took no time at all.

Then I noticed business logic and data access code was embedded into the ASPX files, which in my opinion is a code smell.

So I started cleaning up the solution by moving the code into code behind files.

A bridge too far

After a couple of hours refactoring I realised this was going to take days not hours. So I stopped and asked myself the question: How much value is there for my client in what I’m doing?

What if at the end of day one the client asked how I had got on? By showing them a mock up, prototype or anything else which showed progress I would be able to give them confidence they had picked the
right man for the job.

If I started talking down the previous developers, and how I’d spent the budget on moving code around on a site that was working I might shatter their confidence in me.

So I was stuck between working with a painful solution and providing value to the client.

You can still be a Software Craftsman

I decided only to clean up pages that I actually had to modify. This limits the upfront cost in sorting out the whole solution and delivers value to the client sooner.

I believe the ability to bite your tongue, hold back one’s reservations and make the best out of a bad situation is a required skill for a good developer. This doesn’t mean selling your soul but simply that you understand that delivering value is the most important thing for your client.

By being a good boy scout and making small incremental changes, one day you will have a code base you’re happy with. And from day one your client can feel confidence in you through the value they can see being delivered.

It’s no surprise then the same solution to a problem using Silverlight and WPF applications can be implemented in a number of ways.

In a series of posts I want to show how we can refactor a Silverlight application which “works” to be a lot cleaner, easier to maintain and adheres to good development practices.

Although I’m using Silverlight many of the changes and suggestions would also apply to a WPF application.

So what’s the application?

The application adds two numbers together.

Yes that’s it. Click here to see a live demo of the calclator.

Using a simple example (as opposed to a huge complex monster) allows us to focus on refactoring and making improvements rather than trying to understand what the application is doing and wading through hundreds of lines of code.

So what’s wrong with it?

The XAML is shown below

    <Grid x:Name="LayoutRoot" Background="White" Height="100" Width="350">
        <Grid.ColumnDefinitions>
            <ColumnDefinition/>
            <ColumnDefinition/>
            <ColumnDefinition/>
            <ColumnDefinition/>
            <ColumnDefinition/>
        </Grid.ColumnDefinitions>
        <Grid.RowDefinitions>
            <RowDefinition/>
            <RowDefinition/>
        </Grid.RowDefinitions>
        <TextBox Grid.Column="0" Text="0" Height="25" TextAlignment="Right" x:Name="tbFirstValue"/>
        <TextBlock Grid.Column="1" Text="+" Height="25" TextAlignment="Center"/>
        <TextBox Grid.Column="2" Text="0" Height="25" TextAlignment="Right" x:Name="tbSecondValue"/>
        <TextBlock Grid.Column="3" Text="=" Height="25" TextAlignment="Center"/>
        <TextBlock Grid.Column="4" Text="0" Height="25" TextAlignment="Left" x:Name="tbResult"/>
        <Button Grid.Row="1" Grid.ColumnSpan="5" Margin="0,5,0,0" Content="Calculate" x:Name="btnCalculate" Click="btnCalculate_Click" />
    </Grid>

and this is what the code behind looks like

public partial class MainPage : UserControl
{
    public MainPage()
    {
        InitializeComponent();
    }

    private void btnCalculate_Click(object sender, RoutedEventArgs e)
    {
        tbResult.Text = (Convert.ToInt32(tbFirstValue.Text)  + Convert.ToInt32(tbSecondValue.Text)).ToString();
    }
}

As it stands the application:

• Contains code in the code behind file. OK it’s not so much of an issue for this example and is down to individual preference, but this can quickly become a nightmare to maintain during the life of an application
• Isn’t unit testable – we can’t test two values can be added together
• Has no separation of concerns – the code behind shouldn’t be responsible for adding the numbers together
• A lot of repetition for the styling of the input boxes – if we wanted to make the input boxes bigger we would have to make multiple changes, ideally changes should only need to be made in one place.
• No validation – if the user enters alphabetical characters into application and hits the calculate button the application crashes

So how are we going to improve it?

By taking an agile approach the aim at the end of each refactoring is to have a releasable application i.e. be able to add two numbers together. Therefore each refactoring will involve small incremental changes.

After each refactoring exercise we will review the application to see what improvements have been made and if any new problems have been introduced…

• Step 1: Implement the MVVM (Model-View-ViewModel) pattern to reduce the amount of code in the Silverlight code behind file and follow some best practices for Silverlight development
  
  
  Review: The code behind file looks much cleaner now, thanks to the use of commands and the INotifyChanged interface, but should the ViewModel be responsible for calculating the two numbers together?




• Step 2: Remove the responsibility and concerns for calculating numbers in the ViewModel
  
  
  Review: This refactoring has allowed us to reduce the responsibility of the ViewModel and unit test we can add two numbers together, but we are tightly coupled to the calculator class.




• Step 3: Using SOLID design principles and MEF to remove tight coupling
  
  
  Review: The application is now made up of loosely coupled components which give us a good platform to build upon. But without any validation of what a user enters for a number the application isn’t very stable.




• Step 4: Validating what the user has entered using exceptions
  
  
  Review: If the users input is not valid they are now are shown an error message. This is all very well but the user is still able to click the calculate button even if they have entered invalid values to add together.




• Step 5: Validating what the user has entered using exceptions and disabling the calculate button if there are any validation errors
  
  
  Review: The user is only able to click the calculate button when there are no validation errors. Even though throwing exceptions for validation works, some developers aren’t so keen on doing this so what are the alternatives?




• Step 6a: Validating what the user has entered using IDataErrorInfo
  
  
  Review: By implementing the IDataErrorInfo interface we are able to do validation without throwing exceptions.




• Step 6b: Validating what the user has entered using INotifyDataErrorInfo
  
  Review: By implementing the INotifyDataErrorInfo interface we are able to do validation without throwing exceptions.

Now before I answer this question, I know some of you may have arrived here from a search engine, so if you want a solution check out the MSDN article on converting into a production project in 16 steps but just because you can it doesn’t mean you should!

One of the problems with prototyping tools like SketchFlow is they can sometimes leave your client with the impression that all the work is done the and product is in some way releasable or production ready.

Now I’m not saying nothing can be shared between the two solutions (e.g. resources) because that depends on the design and project you are working on.

What is clear however are the aims and mindsets used to create a SketchFlow prototype are different from how you would go about creating a real world production solution.

From a design perspective the layout of controls in SketchFlow are done using a single grid and their margin property. In a real world application you would pay more consideration into the layout of the design and think about things like how the page would scale.

From a developer perspective a SketchFlow prototype doesn’t easily lend itself to good development practices such as SOLID design principles, code reusability and testing.

And in any case would you really deploy files called something like Screen_1.xaml to a production server?

Even if these things don’t matter to you, I still don’t recommend using Microsoft’s solution because

• there are still references to the Microsoft.Expression.Protyping libraries in a supposedly production ready solution. Having libraries in your application that you not sure are being used before you launch will only get worse as time goes on.
• Microsoft’s solution is not 100% successful, lots of people are having problems with navigation not working properly.

So what should I do?

• Focus on creating designs that satisfy the customers’ requirements and not about the final design. You can think what resources could be reused later in the prototyping cycle.
• Deliver prototypes to your customers early and often. This will allow your customer to give feedback early so you can inspect and adapt.
• Keep your screen designs simple and lightweight so changes can be done quickly and with the knowledge that you won’t be breaking anything.
• Keep an eye on how many events and behaviors are used on a control or screen. It’s too easy to get carried away remember it’s only supposed to be a prototype.
• Take advantage of the sample data resources available and not bind to databases or web services.
• Keep code behind to a minimum, ideally having none at all.

Jag Reehal’s Final Thought on ‘Converting a SketchFlow Prototype into a Production Application’

I can understand why people are looking for a solution where they can use a prototype and a production application interchangeably because like documentation prototypes can easily get out of date and no longer reflect the design used in the production version. Unfortunately the only answer is to adhere to good practices and always start by prototyping and not by retrospectively making your prototype match your production design.

Prototypes are extremely useful… as prototypes and nothing more!

Have fun using SketchFlow I love it, and it’s definitely my prototyping tool of choice.

In this blog post I want to share my experiences and opinions on pair programming.

This is not the first time I have done pair programming and it won’t be the last. I chose the title because when you read about pair programming in extreme programming books, the ideas look great on paper but can be difficult to implement and don’t work in the real word.

Two heads are better than one

Developers who have had positive pair programming experiences write about

• how much more focused they were
• increased productivity
• better code quality
• shared knowledge/less dependency on a single developer
• how it helps new developers learn the ropes
• quicker investigation and resolution of bugs
• on the job training
• why it’s so much better than doing code reviews

On that last point Theodore Nguyen-Cao has made an excellent observation in his blog post Pair Programming > Code Reviews

In code reviews, people sit down to review someone’s code. Everyone has an opinion but not everyone is going to be working with the code on a daily basis. At the time, everyone seems to be involved in the process but there is no vested interest. They are just looking at some code and asking themselves “does this code look good and is it correct?”. It’s a very passive standpoint. On the other hand, pair programmers are completely invested (committed?) in the task at hand. They immediately are using the code they are writing together and collaborating their thoughts on design, code layout, etc. Both programmers are taking on an active role and are emotionally invested in the task at hand because they are attacking the same problem together.

Shared Code Ownership

Have you ever been in a situation where a ‘friend’ has become so attached to their code, they find it difficult to accept it doesn’t do what it’s supposed to or is no longer required?

My best experience of pair programming has been taking over the lead development of a project where the previous developer had been working alone.

When a colleague and I came to conclusion what had be done did not have anything to do with the problem domain, we decided to delete the code and pair together to ensure the same mistake did not happen again. We continued to pair until we had a solid foundation to build upon.

When code is written by a single developer, they will inevitably end up owning it. No doubt you’ve heard something like “that’s Bobs login controller”. If there’s a bug or issue with that code the developer can become very defensive.

When a pair is told the same thing I think it’s a lot easier to deal with because no one person owns the code. In addition developers working in a pair find it easier to accept the path they had followed has come to a dead end a lot quicker than a developer working alone.

Sounds great. Where do I sign?

Hold on comrade not so fast.

Pair programming can be a bit like communism, too good to be true.

One of the most difficult things in pair programming is finding a good pairing partner. The general consensus is that developers need be at similar skill levels, understand the domain and offer something their partner other can’t.

All good relationships are about give and take

Unless you’re a total idiot and couldn’t care what your pairing partner thinks, you will be conscious how your partner is feeling.

If you hog the keyboard too much your partner will become a chicken, involved but not committed. They will play with their phone, think about what to have for dinner, or even fall asleep.

If you’re too passive, not wanting to ‘rock the boat’ you will be putting your name against something you don’t necessarily agree with. This can even be an issue even when you have the keyboard, because all you’re doing is typing what the other is saying. Lets hope your secretarial skills are up to the job.

Some of you will be quick to point out the solution to this problem is to swap the driver/observer roles every 30 minutes or by adopting the ping pong pair programming pattern.

However this doesn’t always solve the issue especially if you’re working with a control freak who says something like “why don’t you try this?” before taking back the keyboard.

In addition to changing roles within a pair, the developers in the pair should be rotated.

In the Turning on a sixpence – No excuses: Concept To Cash Every Week video, developers working on a project for a broadcasting company changed pair in morning and afternoons. This means over a course of two days five different developers would have been involved.

For example in the morning developer A would be ‘driving’, and developer B would be the ‘observer’. In the afternoon developer A, would move onto something else, developer B would be ‘driving’ and developer C would be ‘observer’.

I know this is cynical but I can’t imagine that the first few minutes of a new pair starting aren’t spent bitching about the developer who has moved on, followed another half an hour taking out what they think is wrong and doing what they wanted to do.

Developer Values

There’s no doubt a developer has to make sacrifices when pairing. What if you like doing test driven development, but your partner doesn’t? You could

• suggest to try it out – and then try to look pleased when they don’t.
• raise the issue – because that’s really going to help you build a relationship.
• do nothing – it’s the easiest thing to do and you simply can’t face another day at work wasting time fighting your corner.

A good developer in a pair can’t argue with everything they don’t agree with, they have to bite their lip and let things slide. After all how much value is there in arguing if underscores should be used for private member variables.

Thanks But No Thanks

Many developers have said that pair programming is that it’s not for them.

Lionel Messi European and soon to be crowned World footballer of the year is fantastic when he plays for Barcelona. But when he plays for Argentina things don’t go so well. The problem is the system he has to fit into.

Why should a developer who is able to write good quality code on time be forced to fit into a process? After all that isn’t agile about ‘Individuals and interactions over processes and tools’.

And if you believe ‘people work harder when there is someone looking over their
shoulder’ (see Mendelt Siebenga’s post The dirty secret of pair programming), well that fits in with the Tayloristic view that workers are stupid, can’t be trusted because they don’t care about things and only managers know better.

When I’m working alone and have to solve a problem I can look on the internet Stack Overflow or ask a colleague.

Sometimes when you’re pair programming trying to find a solution is like having a back seat driver on board, you’re unable to concentrate and have to speed read because your partner wanted to click on a different link or search for something else. This clip sums up what I mean.

Harry Enfield Television Programme – You Didn’t Wanna – A funny movie is a click away

On a lighter note some developers have pointed out they don’t like pair programming because to hygiene issues. Sharing a keyboard and mouse with someone who doesn’t wash their hands, or having to sit in close proximity with someone who smells, is not a pleasant experience.

Jag Reehal’s Final Thought on ‘Pair Programming Is Not a Silver Bullet’

Should developers do pair programming all of the time? No.

Developers should be trusted and left to their own deceives. They should pair when they think it’s the right thing to do.

When pair programming works it’s very good, not only for the project but for individuals as well. The amount of keyboard shortcuts and tips and tricks I’ve picked up when pairing is amazing. Check out Keyboard Jedi when you are pairing, it shows a visual list of shortcuts as they are being typed.

It’s important that developers are able to read blogs, explore and experiment, which pair programming doesn’t really allow for because your partner has to agree with everything you want to do. In his PDC 09 ASP.NET MVC 2: Ninjas Still on Fire Black Belt Tips talk Scott Hanselman said ‘you can spot a good dev if their recent project list contains projects where they are just trying out stuff’.

For me code reviews come too late in the development process. Pair programming should seriously be considered if code reviews are of paramount importance to you.

As for the arguments about productivity and focus etc, yes it can help. But I also believe developers working alone and using the pomodoro technique could achieve similar results.

I will never dictate my team have to do pair programming. But I would be disappointed if they never tried.

Why is it important?

The patterns and practices outlined in this book will help you develop more successful software solutions.

How?

Eric Evans shows how you can improve communication with your customer (by doing things like developing a ubiquitous language), implement agile practices and create maintainable solutions which follow good software development principles.

One of common criticisms of the book is that ‘it does go on a bit’.

The good news is that the folks over at InfoQ have come up with ‘Domain Driven Design Quickly’ which summarizes what Domain Driven Design is about.

The even better news is that it’s FREE if you register with InfoQ, which is no bad thing because it’s a fantastic resource with videos, presentations and some very good articles.