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.