My development stack

A couple of days ago I started developing my TranslationTester. To do this I needed to get my home PC up to speed in terms of a development stack. At work I have a pretty much MS stack (Rhino Mocks being about the only exception), but I wanted to see what the open source offerings would be. So currently I have:

• IDE – Sharp Develop, (3.0 Beta 2)
• .Net Framework – (3.5 SP1)
• Windows/.Net SDK – (6.1)
• Code/Style Analysis – FxCop (1.36), StyleCop (4.3)
• Testing – NUnit (2.4.8)
• Source Control Client – Tortoise SVN (1.5.3)
• Source Control Server – Google Code
• Issue Tracking – Google Code

So far I’m pretty impressed, particularly with #Develop. The integration between them all is top notch; One of my worries with Subversion was that to get integrated source control with Visual Studio required a commercial plugin (as far as I’m aware), with #Develop and TortoiseSVN there’s great integration and it tracks and indicates which files you’ve changed right in the IDE.

I’ve setup a Google Code project for the TranslationTester, I’ll start linking to it soon, once I’ve got a bit more up there.

Translation Tester, part 3 – Requirements

In the 3rd part of the Translation Tester series I intend to come up with some initial requirements for the product. This will then be used to create a product backlog and drive development via ‘Test Driven Development’. I’m going to try and express the requirements as ‘user stories‘.

The users

First a quick introduction to the users; I realise that I should probably have some real users providing my user stories, and in due time I hope to add to my initial user stories with real end-user stories.

The Traditional Developer is a developer who writes code and then writes some unit tests afterwards to test parts of their code.

The Test Driven Developer uses tests to drive the design and development of their code

The term Developer will be used to refer to all developers.

The Development Manager manages a team of potentially changing developers over a period of times, potentially on several projects.

The Build Engineer manages and monitors a product’s automated build.

The Stories

So without further ado lets start writing some stories, although they’ll probably go from simple to complex no prioritisation or ordering is intended at this stage.

As a Developer
I want to test my translator classes
So that I have confidence that they work

As a Developer
I want to specify that a property should not be translated
So that I can have minimal classes

As a Developer
I want to be able to clearly see properties that were excluded from the translation
So that as requirements change I can easily identify the changes to be made and bug fixing should be easier

As a Developer
I want to know when my code change has broken another area of the code
So that I can have confidence in making changes without the risk of regression

As a Developer
I want to reduce the amount of ‘boilerplate’ code for testing translators
So that I can work more efficiently

As a Developer
I want to be able to specify complex translations where necessary
So that as much as possible of the translation can be tested

As a Developer
I want the tests for my translator to specify the desired output, not how the output is achieved
So that my tests are more robust, and don’t just duplicate the production code

As a Developer
I want each test to test one aspect of the translator
So that a failed test clearly indicates the reason for the failure and other failures are not hidden

As a Developer
I want to exercise the translator with a wide range of inputs
So that I can test the translator handles a wide range of inputs correctly

As a Developer
I want to be able to use a mocking framework to test that a call was made as part of the translation
So that I can test parts of the translation that do not easily allow for state based testing

As a Developer
I do not want to be forced to use a specific mocking framework
So that I can work the way I (and my team) work.

As a Development Managers
I do not want to be tied to any other dependencies (such as on a specific unit testing framework)
So that I can choose what tools the team will use and change my mind in the future

As a Build Engineer
I want to automate running of the translation tests
So that I can be notified of a failure without any manual intervention

As a Test Driven Developer
I want to be able to start from a small skeleton translator and test class
So that I can get quick feedback on my development

As a Test Driven Developer
I want each small test to indicate the work that must be done in the translator to make the test pass
So that I can use the tests to drive my development.

Translation Tester, Part 2 – Approach

In part 1 of this series I described the problem I’m trying to solve. Before I delve into solving the problem I’d like to take a quick moment to reflect on the development approach I plan to take for this project.

This is the first time I’ve tried to do any development outside of work, so I’m going to acknowledge from the outset that I don’t have a very detailed approach in mind, and I’m more than likely to change it as I go along. This fits quite well with my experience of agile development methodologies, so I’m going to try and put as many of the agile techniques into practice that I can. I’m pretty much development centric, so I’d also like to have a look at some of the related skills relating to requirements analyis and project management.

So as I see it the stages that I’ll need to go through in approximate order are:

1. Initial requirements
2. Iteration 0 – Get a skeleton solution with Continuous Integration etc
3. High Level Design – I don’t want to get into too much detail at this stage, but just taking a moment to think of a broad design might help
4. Find a suitable requirement/use case and implement it using Test Driven Development
5. Analyse what comes out of the implementation and update requirements etc as needed. Lessons learned etc.
6. Repeat steps 4 and 5 until all the requirements have been met.

So that’s my very rough approach, I’m sure I’ve missed oodles, so please drop a comment to suggest any pit-falls etc.

Why do our code reviews take such a long time?

Kevin E. Schlabach has posted in response to my post on code reviewing. I almost decided to respond on my own blog, but thought it was more polite to comment there and just link to his post (and my reply) from here. The main point it made me think about is trying to decide why our code reviews take a long time. I’d be interested in other’s approaches to speeding up code reviews.

Code review, before or after check-in?

Recently I’ve been thinking about our code review process, and how it could be improved. We’ve recently moved from a simple VSS based source control to a more feature rich TFS based approach.

We now have the majority of feature development occurring in several development branches, at the end of each development iteration we get all the changes reviewed and then merge the changes into our Main (or trunk); a build from Main will then be passed to test.

Problems we’re finding with this approach are:

Development Code Freeze

Whilst code is being reviewed (and review actions being actioned) we pretty much freeze feature development in the branch, the code review can often take a long time, so people often start doing further development off-line, ready to check-in once the freeze is lifted.

How can we make sure that what is eventually merged into Main is what was reviewed? 

If the review is done against the changes between Dev and Main then you miss reviewing any merge conflict resolutions (unless you do a 2nd review). If you review the ‘pending merge’ (where someone does all the merge process apart from the final check-in to Main), you risk the merge no longer being valid (someone else checks into Main between pending merge and review complete).

Seeing very little benefit from the review

Our process of reviewing all code going into Main is giving us a false sense of confidence, as we think Main has top-quality code in it; in fact this is not the case, often it seems the only review comments that are actioned are fairly trivial changes that wont take very long. Any fairly major changes are often deferred to a future ‘Change Request’, with the merge going ahead anyway, as the feature is required.

We do want to prevent breaking changes going into production or even to test, but this should probably be caught by testing (automated) and Continuous Integration.

Code review is inconsistent

Code reviews are processed in a fairly inconsistent out-of-band way, with very little formal process around it. Review comments can sometimes be lost, and tracking whether the review was fully actioned etc is not 100% possible.

Suggestion: Do the code review after the check-in to main

So the suggestion I’ve been making is that instead of holding up the check-in to main with the code review we do the code review afterwards. The process would be something like this:

• Feature development is done in a development branch
• Towards the end of the iteration the code is prepared for check-in to main
• The code is merged into main
• The check-in to main causes a code review task to be created for the changeset
• Code review actions are done directly against main.
• Once the code review has all been resolved (actioned, further tasks raised etc). It is marked as closed.
• Before main is pushed to production all feature development code reviews must have been completed.

So if we adopted this process would it resolve our issues?

• Development Freeze – by decoupling review from development the two activities could run in parallel, as soon as the merge is complete development could resume. If merging up to a label you wouldn’t even have to freeze whilst the merge is done.
• Review exactly what was merged – by definition we would be reviewing what was merged. We could even say that review actions should be reviewed so no changes to main go unreviewed.
• Review benefit – by decoupling review from development and making the review process more traceable I think we will be able to add review actions to the product back-log and then even the big changes will be done. Review actions should be treated in a very similar way as feature development with priority dictating what is actually done.
• Review inconsistency – having a proper review process that is tracked with tasks will means a more consistent approach and a reliable process. Any unresolved review comments will be searchable/reportable just like any other tasks.

So what would the cons be?

• I think we would risk checking in bad code to main, and although we could use our source control system to roll these back etc, we might not catch them in time – I don’t think, however, that our current process really stops this happening.
• Reviewing could be neglected in favour of feature development, but this just means that project management needs to see the importance of the review process and prioritise the tasks appropriately.

Accepted Best Practice

Before writing this post I tried to search for the best practice in this area and couldn’t really find any. I guess one answer is that instead of code reviewing paired programming could be more effective. Does any one have any suggestions as to what others are doing?

TALC Driven Development

Recently I’ve been reading several blog posts about the effectiveness of Test Driven Development. Of particular interest is Jacob Proffit’s TDD or POUT

It seems to me that there is Plain Old Unit Testing, which I would argue implies “test at the end” unit testing at one of the spectrum, and then pure TDD at the other end. I see myself being near the TDD side, but not all the way; in fact I would categorise my approach as “Test After Little Code” Driven Development, or Pragmatic Unit Testing. What I tend to do is write a little bit of code first then write a test that exercises the code. From that point I’ll do one of two things, either write another little bit code and then test it, or sometimes write another test which deals with a slightly different case and then write the code to make it pass. Often different situations seem to lend themselves to a different approach.

I’m not sure exactly how Jacob does POUTing, but I’d imagine he doesn’t leave all the unit testing to the end. I think this is the real ‘enemy’ of unit testing, as by the end you are facing all the issues that TDD addresses such as code that isn’t testable, or no time left to test. These issues aren’t only solved by TDD, they can also be solved by incremental unit testing.

Agile: supporting internal change as well as customer change

I had a bit of a realisation moment recently. Whenever I’ve read or talked about ‘Agile’ its proponents have always talked about how it is better for supporting customer change, so if a customer changes their mind part way through the project you are much more able to change.

Sometimes a reason for not adopting agile has been “our customers tend not to change their mind very much, it’s a stable environment. Agile wont bring us anything”. My realisation was that Agile supports change, not just customer driven change but also internal change. For example part way through your project Microsoft release a wizz-bang new tool, that would really help your project, so you want to work it into your project. If you’ve adopted an agile software development approach you will be more able to implement this change.

Missing ‘Test’ ‘Edit’ or ‘Properties’ buttons in Fitnesse

Today I’ve been trying to get my head around Fitnesse, so far it seems pretty cool. One thing that confused me, that I found a neat solution for, is that the help often says press the test button on the page, but there was no test button…

So to get a test button you can click on the Properties button and tick the Test checkbox. That’s great, but what if there is no Properties button either? The same problem sometime happens when the ‘Edit’ button is missing.

The solution relies on the fact that all the buttons do is link back to the same page with a Get query string so to test a page you can simply add ?test to the URL (e.g. http://localhost/page?test). This works but can get a bit tiresome, so you should use the properties page to add the required buttons to the page, so if the Properties button is missing simply add ?properties to the URL, tick the required functionalities and save! bob’s your uncle!