Jamie Cansdale's done it again- he's added Test With -> Coverage to the TestDriven.NET Visual Studio add-in.  A picture's worth 1,000 words:

Once the tests are run it launches Grant Drake's (aka KiwiDude) re-write of Jeff Key's NCoverExplorer.  The NCoverExplorer then displays full coverage stats as well as illustrating the coverage of code blocks.   Here's the output from a run over the NUnit code:

This is awesome work that will make it easier to understand and work with code.

If you like a free day of training on Microsoft technologies presented directly by developers with experience using technologies then sign up for the DeveloperDeveloperDeveloper day that's being held on Saturday 14 May at Microsoft's Thames Valley Park campus.  Don't wait to sign up - we're 75% full already and based on similar events in the US we're likely to sell out completely.  Microsoft have graciously provided the venue and are handling the registration and logistics, but all of the speakers are independent community developers! The www.developerday.co.uk site has a full overview of the event, the agenda and sessions and the speakers involved.

There are three different tracks with 6 presentations in each.  Here are a sample of some the talks from developers I know that I'm looking forward to:

• Alex Homer and Dave Sussman will be talking on SQL 2005 and another secret topic
• Ian Cooper, who runs the London .NET User Group, on Patterns of Data Access in .NET (here are my notes from a previous version of this talk I heard)
• Phil Winstanley, ASP.NET MVP, will be talking about preparing for ASP.NET 2.0
• Craig Murphy, Jedi Scrum Master and XML Web Services MVP, on Managing Iterative Development with Scrum
• I'll be covering What's new with Web Services in .NET 2.0.

I'm also looking forward to hearing about custom attributes in .NET, refactoring, test driven development, debugging tips and writing custom FxCop rules.

As well as the presentations it's also a great chance to network with other .NET developers.  For instance, I know that Jamie Cansdale is likely to be there, so if you've got any questions/comments for him on his fantastic TestDriven.NET addin there's an opportunity.

A big thanks to Mike Ormond and his team (Mike Pelton who first posted about the event) for providing the venue and logistics support.

The command pattern allows you to wrap a command inside an object so that you can pass it to another object to execute that object.  We were using a simplified version of the pattern where we had a command interface that has an Execute method and a Results property to retrieve the results:

public interface ICommand

{

      void Execute();

      string Result{ get; }

}

Objects of this type are then passed in as an IList to a CommandExecutor that loops through the commands and calls Execute on each one:

public class CommandExecutor

{

      public void Execute(IList commands)

      {

            // loop through the commands and

            // call the command.Execute method

      }

}

So we wanted to write a test that ensured that the Execute method was called on each command that we provided to the CommandExecutor.  Initially we thought about sending through a concrete Command (say a ConcatenationCommand) and determining that the result was what we expected.  However, this would have coupled our design to that particular Command - if we made a change to the results that returned we would have to update our tests.  In this case we aren't concerned about the actual result, just that Execute is called on each command.  The question was how can we test this behaviour without having to worry about a concrete Command or its result?

This is where Mock objects come in (see the original Mock paper or the Pragmatic Programmer's overview).  They allow you to test the behaviour of an object rather than just its outcome.  The idea is to create a 'fake' or stub object that validates the object was used in the way we expected.  In our case we could create a MockCommand that derives from ICommand.  We could provide a boolean property - ExecuteWasCalled - on the class that could be set inside the execute command.

public class MockCommand : ICommand

{

      public bool ExecuteWasCalled;

      public void Execute()

      { ExecuteWasCalled = true; }

      public string Result { get { return "result"; }}

}

While this would work fine, since our needs are pretty simple in this case we could use NMock which provides a way of creating a DynamicMock object based on an Interface.  The DynamicMock exposes a property that can set expectations about the behaviour of an object, such as a particular method being called.  The DyanmicMock object also has a MockInstance method that returns an instance of the Interface. Using this technique saves us having to create a concrete Mock command.  Here's the resulting code:

While I still have reservations about the extent to which MockObjects are useful, I think that NMock and its DynamicMocks are a useful technique to quickly produce loosely coupled test code.

Should we write test code against interfaces or something more abstract than the implementation?
James mentioned that MBUnit is a tool that allows you to test against an interface.  The question was whether you should create interfaces that enable tests to be written against them in case further implementations were created in future.  James' attitude was that this might result in wasted work ('you aint gonna need it') since you may not need it, or may not need it now.  Instead, abstract things out when you need them - don't create an interface just to test it.

James also said that an interface is not a good example of the contract of what is being done - it is the name of the method with input and outputs, but does not reflect how the method reacts to the input. James writes tests that show the real interaction between someone that calls the code and what it produces.

How much of the class should we test? Public methods only or protected and private methods as well?
Around a third of the group thought you should test protected and private methods, about another third thought that we should only test public methods.

The arguments for testing internal and protected methods:

• To ensure that the internals work. One delegate mentioned writing a test before each internal method. Someone else said the start with the public method then refactor and hide the method by turning it private.
• Another argument was An argument is that if you write a granular class with lots of private methods, then the tests should be just as granular as the thing being tested.
• The internals are the most important as they contain the biggest areas of logic, so they should be tested directly.

The argument for testing public methods:

• Private method tests inhibit refactoring - you have to refactor your tests with a change, increasing the burden and making it less likely that the tests are updaed.
• You may need to test all of the scenarios from the real world against the public method. If your class is written well then the private methods should be tested.
• If you separate the tests from the production code then you must test the public methods.
• Using public methods gives you a clear limit to the number of unit tests that you need. Public tests will get most of the issues, there's no payback from more investment by testing private and internals.

James says that there is no winning this argument. He favors testing the public interface because it decouples the test from the implementation which will discourage refactoring. However, there are cases where it doesn't make sense to expose something just to test it. He thinks it is 80/20 or 90/10 favouring testing through the public interface.

Whidbey will have friend assemblies that allow developer's to split two assemblies, this other assembly is akin to being inside the same assembly. You can do this today with a multi-module assembly built through the command line, not through Visual Studio.

How do we introduce Unit Tests to a 'legacy system' without tests?
No one in the session had seen legacy code that is easy to test if the testing hasn't been thought of upfront.  One person mentioned that they created tests for each issue logged through the help desk and then used these as a regression suite.  This also demonstrated the value of unit testing to their organisation.

James suggested drawing a line around a piece of the code that you need to change. Test it's external behaviour, make changes and ensure the tests still run. They aren't unit tests, but who cares? Create a boundary, create tests and then change. The key point was to conserve effort and only write tests on things that you are going to change.

James also mentioned a book to be published in September by Michael Feathers called 'Working Effectively With Legacy Code' that describes how to handle this difficult situation.

How to convince people to do test first? Argue against the concept that it will take too long to write the tests first?
One delegate mentioned that this is hard because the best way to convince people is to show results, which requires a practical example, which means you have to know how to do it (what classes, how to unit testing). It takes time and experience but it will work eventually.

Someone else mentioned the green bar of success (my favourite) on the screen is a big part of demonstrating it.

You have to make sure the person has the right mindset. Not everyone has a zero-defect mindset. They want to write tests more than write code.

James says the story is not about the individual developer who wrote the code and knows it works. It is about the team and the ongoing evolution and maintenance is where the tests matter. How can you be confident of your result without them? With unit tests I know they works, before I relied on something else, but now I know.

Why should we write the tests first?
James says that no one will take my word for it. What convinces people is having to test something that hasn't been created with testing as a priority. If a setup method has 20 lines of code and many objects being created and only contains a single assertion - it wasn't written with testing in mind. Someone will say it is really hard to test it.  So the next question is 'What would you do differently?'  The answer to this question is what people should do in Test First.

James said that he believes that testing has to be seen as a primary part of development. We have to incorporate test inside development. There may be QA, but they start at a different level. You have to incorporate testing as part of development.

In the PAG group they have 2,000 unit tests that get run against the library every time someone modifies the code. When James talked to the testing and QA group who do integration testing -they didn't know what to do - the unit tests did the easy part of the testing. They have to start at a higher, more complex level to start thinking about critiquing what is going on rather than I just pass 32,000 characters in a web app and it breaks. These are necessary tests, but it doesn't take a lot of skill to do these types of tests.

Someone made the point that software development lags behind electronic engineering where hardware must be tested first.

James mentioned that studies have show that Test First is 16% longer, but the quality was much higher.

How do you test a function that is dependant on other objects or libraries?
One delegate mentioned that using Dynamic Mock objects relied on finding a sweet spot.  They are useful with objects that have relationships, but the problem is that if you refactor your code then it is highly likely that a whole slew of tests that will break.  The problem is compounded with dynamic mocks since you only see this at run time rather than compile. It works well at mocking the database, but not the more dynamic

James described mock objects as the situation where object A interacts with objects B and you need some way of 'switching out' Object B to create a 'dummy response' from the calls of Object A.

James believed that if you are interacting with something complex, building the simulation of something that is complex is a worthless activity - you spend more time writing the simulator than the test and it doesn't tell you anything? Just because my mocks work, does my real system function?  James uses a rule that if mock objects have an if statement inside them then that's too far - the behavior is too complicated and there's no value (it says there are multiple situations). They do have value, but we need to separate a simulator and a mock object. For example, writing a mock JDBC implementation - that is way too complicated.  Be skeptical of spending a lot of time spending time building MockObjects.

Someone asked - 'Don't you think that it depends on the situation?' James: "I could answer everything that way"

James mentioned the Inversion of Control pattern - this is the a situation where object A depends on object B - the developer wants to be able to switch object B out as a mock or a stub - how can we do that? Inversion of control says you create the dependent object B, or a mock or stub external to object A and then pass it into object A as a interface parameter in a constructor. That's a lot of complexity to add to the initialization,  James was interested in opinions about whether the complexity is worth it?  He mentioned that some people have pushed back on the idea because of the complexity of the construction - if all you are doing this for testability (it also decouples the design) then it is too much work?  He believes that what has to happen is that we need different language structures and we will never get there if we dismiss these ideas now. In the Java world there are lots of work being done on using containers in another way.

How do you we test the database? Where do you get your data for testing? How do you unit test things that involve the database?
James thought that the problem with the database is similar to the MockObjects. It is a lot of effort to Mock out the database. Sometime it is easier to use the database than mock, you need a database to run the unit tests and you have to fill the database, read in a dump, which takes longer and is more effort.

James' experience is that at some point you write tests against the database because he wants to test that the Data Access Layer works. When he write DAL tests he uses the database. But he don't use the DB for anything that uses the DAL - he mocks them out. A technique he use to ensure he's written good unit testing is to deliberately break something and see the results.  If he finds a cascade of errors, it means he hasn't isolated the tests correctly.  He also mentioned that if he comes back to an a feature afterwards and spend a lot of time in QA it means he didn't do well enough with the tests.

With databases,  it is a good idea to  use a transaction and rollback the transaction at the end of it to ensure that.  There was some discussion about how to construct database tests.  The problem with building the database in scripts the unit tests take too long and they wont be run. How long is too long?

How long should the tests take?
There were a range of experiences including:

• Four or five machines run it each product, it takes 6 hours across machines.
• Someone else has developer tests and then smoke and build tests, it can take a long time in the nightly build.
• Another project had two CruiseControl systems that built at different intervals, running a short and long set of tests.

James thinks an hour is too long - the reason is that ideally you would be able to get very quick work around. This is how it works successfully. Waiting an hour for the feedback means that a developer could only make 8 or 10 changes a day. In that hour a number of things are accumulated. James mentioned his experience on an early project where it took 12 hours to recompile that application.  In this project if someone made a change to a header file in C++  they had to recompile, so what they'd do is create global static variables instead of the header to ensure it works before 'doing it correctly' (which was never done). Sorting out problems was very complex because it was effectively an integration nightmare..

Should all developers run all tests? It depends on the architecture - if there are subsystems you could do that. In XP it says all of the tests all of the time. James' group run 2000 tests in 340 seconds against 3 databases.

How do you manage dependence tests with the database? How to restore state with persistent storage.
It is a good idea to stub out the system so that you can test against something that you depend upon. Then when the implementation is delivered you can run the tests and it becomes clear where there is an integration problem.

One delegate spoke of how he stubs out the system, then write tests and implementation, then the stubs are removed and the real implementation of the rest of the tests are done. The platform should support this - James mentioned a project where he used 'linker polymorphism' - relied on the linker to substitute.  Another delegate said they had written something that as part of the the daily build checks out the project file, it changes the XML structure of the C# project to switch references and changes them to the actual assemblies.

How do you test concurrency? Multithreading?
These are just really hard. Testing timing problems with unit testing are hard. One delegate spoke about how he had written unit tests for a multithreaded apps and said it was one of the best examples to convince others of the value of unit tests. It took 2 months to create, but then it only took 1 day to shift it from Java to C#.

The xUnit tools should support this but don't make it any easier.

Another delegate used a timer library and extended the Nunit assertion.

Roadmap for MS
VS Team System will include unit testing support some time next year. It will have a number of integrated testing tools. The keynote yesterday showed a tool 'very much like' and 'subtly' different tool to Nunit. James will be talking about the difference.

There are load testing tools, web testing tools in there. It is a team system that is extensible by many different partners. Many partners, such as CompuWare (did a functional UI testing), doing stuff inside this 'platform' that can be extended.

Someone will write something that will allow Nunit to execute in this environment.

How do you generate tests?
Team system will create a stub test from the code. These are just boiler plate - it doesn't do analysis of the running code and propose a 'good test'

One delegate had a poor experience with a tool that created tests automatically because the tests didn't take into account the intention of the class which resulted in the tests failing. Writing the test manually is more useful as these can act as a specification for the class.

James thinks looking at the implementation to drive the tests is looking at it the wrong way. If you wrote the implementation wrong and then create tests off these, what's the value? The tests should say 'this is what the implementation should do'

People often propose this if they haven't done unit testing before.

How do you test distributed applications?
It relies on subsystems - just write tests that test the local machine, when you have to integrate it all together you might need to run tests, but these are not unit tests in this situation.

How do you unit test GUIs?
One delegate used Rational Robot - costs a fortune. If you are careful and script it then you can get away for a few builds without it breaking. SendKeys was also used.  Another person just avoided the problem by trying to get all of the functionality out, recognising that it is hard to test the UI.  Someone said that it is hard to test drag-and-drop operations.

James menioned that Robot is not good to drive development because they require the UI to be done, but it is hard to do.  NUnit Forms and NUnit ASP were also mentioned.

What frameworks can you recommend?
Nunit, csUnit, mbUnit, CLRUnit
HarnessIt (commercial)
Xunity (Commercial)

How do you do Web unit testing?
HttpUnit works, but it is Java, these can be used successfully to drive HTTP requests and do some testing on the HTML that is returned.
They suffer from many of the brittleness problems that the robot testing does - you have to use id's on the elements - but it requires a lot of thinking about how you output.

Along with Jan Erik Sandberg (founder of the Norwegian Extreme Programming Forum) I'll be running two Chalk and Talk sessions on Extreme Programming at TechEd Europe.  We're going to use a 'Fishbowl' format, sometimes described as a Park Bench Panel.  Ward Cunningham describes this format as 'very much like a wiki for people who happen to be largish in number and stuck in the same room’

Here's how the format will work: we'll start with a panel of speakers (James Newkirk will be with us for the first session at least) 'in the goldfish bowl' on chairs at the front of the room, along with one empty chair.  The rules are that those in the audience, outside the fishbowl, are only allowed to ask questions.  If you would like to say something then we'll encourage you to walk up and sit in the empty chair.  At this point discussion stops until one of the panelist leaves so there's always an empty chair.

Here's the blurb:

Are you interested in Extreme Programming?  Have you thought about starting an XP project?  Do you want to know what works, what doesn’t, what the risks are?  This Chalk-&-Talk is a great opportunity to meet with other interested and experienced practitioners.  We’ll use a ‘fishbowl’ discussion format – an extreme way of having an active group discussion described by Ward Cunningham as ‘very much like a wiki for people who happen to be largish in number and stuck in the same room’.
Wed 30 June 2004, 08:30 - 09:45 Room S
Fri 2 Jul, 16:15 - 17:30 Room S

SecretGeek announces a sexy new methodology - TODO Driven Development [via Mike Gunderloy].  There's a full description of the process (there's even tool support in Visual Studio 2003!) and this at the end:

Does giving it a name make it legitimate? Can I write a book on this and do a lecture tour now?

Too funny. 

Jim Newkirk got his 'day in the sun' to speak about Test Driven Development and the tool out in public promoting Test Driven Development and the tools support he's been involved with using Microsoft Visual Studio Team System.

He started out with a quick audience poll of how many people had heard of Test Driven Development (around 80%) and how many were actually using it (about 30%). So a clear victory for marketing over behaviour change there!

The Two Tenets of Test Driven Development:

• Never write a single line of code unless you have a failing unit test.  The goal is to take requirements and express them as test
• Eliminate duplication

How to do TDD
Jim starts by blocking out 4 - 8 hour sessions of development. He spends 15 - 20 minutes at the start of each session thinking about what he is going to do and brainstorming a list of unit tests.

A key part is not to get hung up on completeness, you can always add more later. The purpose of the tests is to describe completion requirements.

The flow of a TDD session: Red, Green, Refactor
The process is:

• Start by writing a test for a new capability
• Compile
• Fix any compile errors
• Run the test and see it fail
• Write the code to make the test pass
• Refactor as needed (clean up any duplication)

The purpose is about how to use the functionality, not how to implement it! The process allows you to build confidence through having a set of tests that pass.

The most successful way to do test is to do it before the development. If you start it first then you need to think about how to test.

Features in Visual Studio Team Systems
Jim used a stack example to demonstrate the process of TDD as well as the support in Visual Stuido Team systems. The first test looked as follows:

[TestClass]
Public class StackFixture
{
   [TestMethod]
   Public void IsEmpty()
   {
      Stack stack = new Stack();
      Assert.IsTrue(stack.IsEmpty);
   }
}

So, the same approach as NUnit, just with new names!

One cool feature was writing a class name followed by a method name that didn't exist yet. After compiling, Jim used a 'smart tag' to choose to create the method stub inside the target class. It wrote this stub and had a 'NotImplementedException' inside it. This is functionality similar to Eclipse and is good to see.

While writing about Jason Bock's experience with XP I started feeling a bit bored with asking 'Does XP work or not?  Should everyone be doing XP?'.  I read Alistair Cockburn's PhD Thesis that presents a convincing argument that no one methodology will ever be the right way of doing things,  that clever teams will find ways of selecting their methodologies at the start of a project (he gives several key criteria) and that people are really the most important part of it (which is why I'm surprised that so many organisations fail to imitate Microsoft's well-known and documented hiring process).

No methodology is going to be a silver bullet

To me this is useful because it provides a framework from which to view XP and other methodologies.  So XP has some good practices in it, but the notion that it's the only way to do things, or that it will work on all kinds of projects and that all of the practices are required for a successful project is plainly silly.

Questions like 'Is Microsoft doing XP?' aren't really important.  What is important is that any development group thinks about what works, reflects on experience and experiments with new practices to see if they make sense. 

Big methodologies can inhibit reflection

Sometimes I think that the 'big name' methodologies are harmful because they reduce the likelihood that a team or project manager will reflect on their practices.  Methodologies are often attractive to management and project leads because they are packages as an easy solution to the difficult problem of thinking about what practices are best for a particular situation.  I know that RUP says you should customize the methodology to each project, but in reality I've rarely seen this happen.  It's much easier to just use the pre-packaged methodology than it is to think and reflect on experience to develop a custom methodology for each project.

Reflection and customised methodology are harder to market than a brand-name methodology

Saying "We're Agile" or "We use XP" is much sexier and easier to sell than saying "We understand a range of software development practices and use them to create our own methodology at the start of each project, based on the characteristics of the project and reflecting on our previous experiences".

I'm a big fan of the approach that Steve McConnell takes in Rapid Development where he presents a range of software practices that can be used.  For each one he details the amount evaluates things like potential to reduce schedule time, improvement in project visibility, effect on schedule risk, chance or first-time success and chance of long-term success.  The problem is that this isn't as easy to market as other methodologies. 

While I was writing this post I came across the following post from Bob Martin on the Yahoo XP Mailing List who seems to be saying that it's more important to focus on the practices and attitudes (such as the principles behind Agile manifesto) than it is on the brand names:

I'm noticing that the industry is adopting agile practices and attitudes without needing or wanting brand names. In the last year I've worked with a number of teams who started with SCRUM, or XP, or FDD, and who have since been picking and choosing practices from the other methods to suit their needs ... Instead of increasing specialization, the industry seems to be building a body of agile knowledge that it can use as a resource help them build something useful to them. It would not surprise me to find that in ten years the words Agile, XP, Scrum, and FDD have become synonyms.

Recently I've been reading Alistair Cockburn's PhD thesis People and Methodologies in Software Development.  He argues that people are more important than methodology, there's no one methodology that will always be right (and there will always be new ones coming along) and that successful teams create their own methodology based on the needs of the project and the people involved.  Here are the key notes that I took while reading it.

Alistair poses three questions in his thesis:

• Will there always be new software development methodologies, or will there be a convergence at some point?
• If there is a convergence, what are the key characteristics of the methodology?  If there is no convergence, how can project teams deal with the number of methodologies
• What's the relationship between a project's methodology and the people on the project.

Here's the essence of his results:

• Yes, there will always be new development methodologies.
• The best way to deal with a large number of methodologies is to help a team understand what to consider when constructing their own methodology for each project.
• The people on a project team are a 'first order construct' and are more important than the methodology involved.  The characteristics of the team will limit any effect of a methodology.

His thesis is mainly composed of articles that he has written over the years.  Here are the summary points from these articles.

Observations on methodologies and project success
He based a lot of these findings on his own research of teams.

[When interviewing successful projects] what I find striking about these projects is that they show:

• Almost any methodology can be made to work on some project.
• Any methodology can manage to fail on some project.
• Heavy processes can be successful.
• Light processes are more often successful, and more importantly, the people on those projects credit the success to the lightness of the methodology.

And elsewhere:

I ran the seemingly odd hypothesis that if you simply put four people in a room with whiteboards and computers, give them access to the users, and have them deliver running software every month or two, they would have a high likelihood of success in delivering useful, working software. Surprisingly, this hypothesis has not yet been broken.

Methodology is irrelevant in small teams
A key concept is that one methodology can't fit all projects.  Team size is one aspect to consider:

… discussions about methodology are largely irrelevant in small-scale groups:

If the team consists of only two to three people, then the methodology as a distinct topic may be inconsequential. But as the team size grows, coordination issues become significant, and therefore more consideration must be given to the methodology.

Wayne Stevens of the IBM Consulting Group illustrated with the following anecdote:

If only a few drivers cross a large parking lot at night, when there are no other cars, it doesn't matter where they drive. The few drivers can arrange to avoid each other. As the number of cars moving through the parking lot increases, eventually it does matter. With increasing number of drivers, it becomes more important that they establish and follow conventions about parking, driving lanes, and stop signs.

How to select a methodology
When selecting a methodology, some things to keep in mind are:

• Team Size has a big impact on the methodology
  • The larger the team the larger the methodology
  • The more critical the system (the more important the lack of defects) the more important that the methodology is publicly visible.
  • Often there are two sizes that work for a project - small teams using lightweight approaches and larger teams using heavier approaches.
• The quality of the communication impacts the choice of a methodology
  • The richer the communication quality, the less need there is for bureaucracy.

People factors that contribute to a project's success
Things that impact the influence of people on a project's success:

• Communication.  The best way of communicating is face to face with a whiteboard.
• Tending to consistency.  It's important to have the discipline to keep working on a consistent way (when the natural inclination is to get sloppy over time).  This is also why high-discipline methodologies (such as XP) are considered fragile.
• Good citizenship and looking around.  Alistair's quote 'A common answer to asking why a project succeeded at all is: "A few good people stepped in and did whatever was needed to get the job done."'.  This is similar to Martin Fowler's concept of the wandering architect.
• People vary.  Methodologies need to fit the people on the team otherwise they will be rejected.

Barely sufficient methodology
Alistair looks at barely sufficient methodology.  He believe the following factors are sweet spots in these types of projects.

• Two to eight people in a room where they can communicate quickly and easily.
• Onsite customers.  The ability to get questions about the customer's requirements answered easily.
• Short increments.   Deliver a working set of software every 1 to 3 months
• Fully automated regression tests.  That give feedback as soon as possible.
• Experienced developers.  Experienced developers are much faster.

Recommendations
Every project need to develop its own custom methodology based on the characteristics of the people, the project's specific priorities and the technologies being used.  Other important criteria can include team size, geographic separation and project criticality.

It's important to have times of reflection where the team can think about how successful the methodology has been and reconsider and adjust their working conventions.

Jason Bock writes about his experience with Extreme Programming for the last year. I like retrospectives (see Johanna Rothman's blog on Managing Product Development for a good set of questions to use in a retrospective) and people reflecting on experience and thought some of his observations were useful.

Things he likes:

• TDD and refactoring - makes it easy to change the code knowing that tests will pick up any problems.
• Pair programming because it gives quicker feedback on the work as it's being done.

Things he doesn't like:

• Stories. He thinks that the concept is too vague and there isn't enough investigation given to system requirements
• Feeling of it being a religious practice. It's better to treat them as a set of practices rather than religious commandments.
• The coaches often refer to 'the scriptures'. Jason says 'it's weird to hear the XP coaches that the company brought in for these projects to say "Well, the XP process says …".' rather than considering what practices might work.
• He thinks it's harder to get a pulse on the project as a whole. This is interesting as would have thought that the frequent iterations would have generated some

Overall I like the sound of Jason's pragmatism when he says that for him it's a lot more important to 'get it done!'. I've always liked the question 'what do I need to do today to make this product ship on time in future' (I think I read this in Microsoft Secrets years ago).

This session was led by Steve Freeman and Keith Braithwaite and was focused on what has gone wrong on projects that have done XP.  See James Robertson's post for a blow-by-blow description of the session.  I enjoyed the opportunity to hear the experiences of others who had applied XP.  It also highlighted some of the issues I have with XP.

The difficulty of the Customer role in XP
As I've said before, I think one of the weakest aspects of XP is the way it abstracts away the complex and difficult problem of understanding and designing software for customers behind a simplistic notion of an 'onsite customer'.   The danger from my point of view is that XP projects may ignore the benefits that good business analysts and interaction designers can bring, in lieu of developers just working directly with a customer. 

Even with these reservations, I really do like the way XP focuses on the customer.  One of the problems bought up in the group discussion I was involved with was that often developers are forbidden from talking to customers.  I think developers should definitely have access to customers, or at least 'personas' if the real customers are difficult to get to, and that good projects will also employ other people who have experience dealing with customers (such as BA's, integration designers and even usability experts).

Other points raised included that proxy customers must know their place.  Knowing the problem domain does not mean that someone knows how the solution should work.

Another point was the importance of standing up to the customer and challenging them rather than taking everything they say as correct (they are not always right or always able to say what they want).

The danger of XP sounding like a religion
One of the points was that 'dissenters should be tolerated as long as possible but no longer'.  The point was that one 'professional skeptic' can bring everything to a halt.  Another comment in the session was the need to understand the 'rigour of the disciplines'.  While I understand these points, the language concerns me as it sounds too much like XP is a religion.  This problem was acknowledged later in the session when it was highlighted that it was important not to frighten the customer by being a 'religious fanatic'.

Although XP isn't XP without all of the practices, these still aren't enough
Even though there are a lot of points about XP isn't XP without all the processes, it was also mentioned that the core practices aren't enough on their own.  Mistakes are sometimes made on projects where people have 'read the XP books' but not talked to anyone experience (there were a lot of XP coaches in the session). 

Keith said that mentioned that things like version control are 'assumed' in the core practices but need to be done on professional projects.  Other practices included doing some small design up front but avoiding big design up front (BGUF).  UML diagrams were OK, provided they were just on a whiteboard and not written down.  Also the test/code/refactor cycle wasn't enough to guarantee success, you also required knowledge, skill and experience (to know when to stop for example).

One of the comments I heard at the conference was that a lot of the successful XP projects have very talented people working on them and that this was one of the reasons for success. Any project with successful people is likely to do well, irrespective of the process.  To me this doesn't mean XP isn't useful, just that it may not be a processes that can be applied to all teams.

This session was run by Alan Cameron Willis who works with the Visual Studio team out of Cambridge in the UK. Domain specific languages are meant to express requirements and solutions of a particular business domain. Alan is working on the tools like Whitehorse that are visual designers included in Visual Studio that help development teams design and build applications.

We worked in groups to come up with our own domain specific language that we could use. We were asked to imagine that we had created a Point of Sale system for a restaurant and wanted to sell that solution to different types of restaurants (burger bars, bistros, drive-thru's).  Could we come up with a language that could be used to help model, sell or create the software for these different settings?

Alan suggested a range of different communication from text, to different types of diagrams (e.g. UML), to animations. The key issue from my point of view was who the language needed to communicate with and for what purpose. Is the language for communicating requirements or is it to capture requirements and generate the code?

It's nice to see that Microsoft have highly academic involved in creating their software, and that guys like Alan are also turning this into useful tools such as Whitehorse that we can use as developers.

Alan has posted a summary of the domain specific languages discussion on the OT2004 wiki.

I'm attending OT2004 conference (Michael Platt is also here and has blogged day 1) and had my first chance to hear Martin Fowler talk.  He did a keynote on MVC Patterns and the role of an Architect in an XP Team.

What is the MVC?

• Model - maintains state
• View - observes state and projects it to the user
• Controller - poked by user events and sends them to the model, which does some domain interpretation

The key idea is to avoid having domain logic inside the UI.  MVC is hardly ever done in the classic way.  There are two ideas inside MVC, one which is popular and one that is unpopular.

Separate the model from the view and the controller
The popular concept is to separate the model from the view and the controller.  The advantage of this is that things are layered, decoupled and separated.  The domain doesn't know anything about the presentation.  This is a Good Habit.

Separate the view and the controller
The less popular concept is to separate the view and the controller.  The original idea was that you could swap our or change the controller.  So if you had a read0only screen you could swap out the controller to ignore user 'pokes'.  The problem is that user controls often combine the view and the control.  A widget can receive input and display the results.  This second concept is often misunderstood and is one of the reasons for tangled descriptions about MVC. 

How MVC was messed up
One reason was the idea of Interface, Entities and Controllers.  The idea is that an interface represented the UI, the Entities represented the domain objects and the Controller was an intermediary that glued the entities to the interface.  The problem with this approach is that the Entities ended up just being structs and all of the behaviour was in the controller which was essentially procedural coding.

A lot of languages are out there but there is a shortage of OO code.  Martin wrote about this in the anaemic domain model - the domain model is just a thin wrapper around data.

Some people have solved this with a service layer.  The idea is that some of the logic associated with talking with other systems that is not wanted in the domain model.  The question is how to mix them.  Martin's view was that it was OK to have a thin service layer, but the key was to avoid having nothing in the domain model.

MVC variations
Based on talking with TW and others, Martin believes that there are two variations to the MVC model.  These are the presentation model and the model view presenter.  The drivers of these variations is testing.  This is another situation where testability has some good effects.

All too often there are two tier architectures where everything is in the view.  Testing in this approach is about driving the application through the UI.  This is too hard to keep updating, the test are fragile and it never works in practice.

So these variations are responding to the need to test without having to rely on the user interface.  One approach is to keep the view so stupid that you don't have to test it.  Another is to put the logic somewhere else.

Presentation Model
One key problem with the MVC model is that the view couldn't be a simple projection of the domain model.  Often you need to alter the data for the user interface.  Sometimes this is trivial, sometimes it isn't.  It's also hard to mix UI widgets with these adaptations.  Also, there is a need to store state that is about the UI and not the model (e.g. is this control disabled, is the text visible?).  Where should you put this in the MVC model?  The change is to have a presenter that is responsible for adapting the domain model for presentation and holds the view state.  It's also responsible for the synchronization with the state of the widget.  In the Presentation Model approach you can ignore the view and test the presentation which works as long as the synchronisation between the presentation and view is so simple.

The MVP Model
The twist in this approach is that the controller can't respond to the user's pokes.  The user pokes the view and the view pokes the controller (named the presenter in this model).  The Presenter tells the widgets to updated and then updates the underlying model   In the MVP model you can use Mock Presenters and test the messages are coming in order.

How do we group as a profession?  How can we improve what we do?
Martin's view is that we should have reflectors who wander around project trying to push our knowledge and practices along.  A lot like Martin really.

Why does XP have no technical lead?
This is where Martin spoke about his observation of David Rice at ThoughWorks and the way he worked as an architect.  He believes there are two views based on how you view the relationship between programming and design.  See his article Who Needs an Architect for more information.

Architects as Controllers
One view is that architects are the ones who come up with what has to be done and the programmers simply implement it.

Architects as 'Guides'
Architects in Martin's view should be someone who is still involved with a project but should be wandering around the team seeing things, making sure that problems are addressed.  Architects should be reactive to problems, and teacher-like helping to mentor the students.

The key for Martin was the architects should stay close to development, lest they become part of a centralized architecture team responsible for process and policy and really haven't developed in a long time.

Relation between XP Architects and User Interaction Architects
Martin believes that web UIs are popular because they are simple to put together and cheap.  Martin's beef with people like Alan Cooper and Interaction Designers are that they don't factor in the cost of designs.  Good Uis are expensive.  Martin handles this in XP by making a simple UI a user story then telling the customer to create another story for a better UI.

What's the link between the MVC and Architect topics?
Reflection.  They key is that Architects must be able to reflect on experience, which is hard.  They should look for what it is being done, decided what is good and bad about it and then communicate that knowledge to a wider audience (sounds a lot like an author doesn't it?)

Martin is a reflector on other reflectors, a sort of meta-reflector.  He mentioned that reflecting on experience is key.  It's the difference between a 9 to 5 job and someone who wants to get the best out of what they do.  Martin left us with the message that 'I have fun, you should look for opportunities to do that too'.

Another great night at the Extreme Tuesday Club where I met Chris Matts, a Business Analyst (or Agile Business Coach) who works for ThoughtWorks.  It was an interesting discussion about the role of an analyst in a XP/Agile project.  Chris views his role as helping the business customer and the development team get closer together and helping the developers learn more about the customers' domain problem.  This kind of thinking about software development practices is a key reason why I like the XP/Agile movements.

I'd heard about the great work Chris had done on a large project that was going off the rails.  By tracking close to the business issues he was able to influence the project being cancelled and restarted.  We spoke about how to influence projects when it's obvious they aren't going to be successful, the complexity that can be involved when the contract work depends on the project continuing and the personal integrity involved in sticking with a decision you believe in.

I was interested to find out more about how a Business Analyst fits into such an Agile-oriented work place.  To me one of the big gaps in the Extreme Programming methodology is the generic concept of 'The Customer'.  It's a great thing that a lightweight methodology exists that is pushing the importance of customer involvement, but to me XP is thin on the details of what's involved.  In XP Refactored the authors point out that the notion of the onsite customer is a difficult idea to achieve.  Most work places wont allow their best people to leave the workplace in order to sit alongside the development team.  Even if they did they aren't always able to effectively communicate with the team.

Chris' concept was that he understood the technology and the business domain knowledge.  He believed that one of his benefits was to bring the customer and the development team closer together.  He was more effective than just a customer because he was skilled in learning about the business problems and analysing the requirements for a solution. He believed he had a role to play in an Agile team by viewing his role as the Business Coach focussed on transferring his business knowledge through to the development team.

One of the techniques that Chris mentioned as being effective was having the customer draw the business model on a blank sheet of paper at each meeting.  They found this produced much better customer feedback than they received from the customer reviewing their diagrams.  Drawing and talking about the business model produced a greater involvement than someone simply reading and reviewing a document.

Chris had extended this idea further with the concept of producing documents as a way of learning more about the business himself, but not necessarily publishing or sharing those documents with the team.  A very 'Agile' perspective that says the value of the analysis is the impact it can have on the rest of the team.

Quite an interesting discussion developed around the concept of 'How People Learn' or how a Business Analyst could help the team learn about the business.  I take the 'constructivist' perspective which says people learn through constructing their own view of the world.  The key to learning is to engage people in thinking in order to develop more sophisticated connections between concepts.  Any activities that encourage people to actively think about topics and relationships between topics are good.   Drawing a diagram and talking about it are much more likely to engage someone in thinking than passively reading or reviewing a document.

Pair programming with Jamie Cansdale at ThoughtWork's London Geek Night last Wednesday highlighted how much I like this practice.  Geek Night is basically an open night for developers who want to work on projects (ranging from open source development, to personal hobby projects or just for those who want to experience pair programming).  Jamie and I were working on creating a Visual Studio Add-In to remove unused 'using statements' in C# files (essentially, to replicate the 'Imports Tidy' functionality provided by C# Refactory that Scott Hanselman says is almost worth the price of the add-in alone).

Here were the things I enjoyed about Pair Programming:

• Knowledge sharing.  The knowledge transfer ranges from ways of using Visual Studio ("what did you press to get that?") to how to structure unit tests ("would you split that into a second method?") and features of the object model ("how can I find the assembly that defines this type?").  Even in a short session there's a great amount of knowledge that can be transferred.
• Continuous development speed. When sharing the 'driving' seat it means that it's possible to keep developing at a constant rate.  When I develop on my own sometimes I find it hard to keep going once I've achieved a certain milestone.  In Pair Programming it's possible to sit back for a while and let the other person drive.
• It makes you braver. Pair programming provides courage to start having a go even at complex problems.  It's easier to get started attacking a problem using two heads at the same time.

We started out by discussing how to implement the functionality.  Jamie was arguing for a brute-force but fool-proof mechanism of using a regular expression to search through the code, comment out any using statement that it finds and dynamically compile the code to see if it generates an error.  I was itching to write my own stripped-down C# parse that could scan through the source code and understand the using statements (including the alias keyword and nested statements).  To settle the stale-mate by switching our focus from the implementation to the functionality.  We decided to write the tests first (yes, XP is a simple set of practices but it's easy to get off track).

The beauty of writing the tests first was that the tests were independent of the implementation.  After writing a couple of tests it became clear that Jamie's approach was likely to be 'the simplest thing that worked' in the two hours that we had.  The best part was that we were able to achieve a working implementation inside this time!

I'm still eyeing off the SharpDevelop open-source C# editor, which as C# parsing code which I'm tempted to use (or maybe it's time to get into Mono), but for now I'm sold on the value of pair programming and test first development.

Two pieces of news have made this Valentine's Day a geek day of love.

• JetBrains, the creators of IntelliJ have released an ealy build of their C# tool, ReSharper which I have been waiting for.   Luke Hutteman has a good review of the features (and info on how to access the download site, which currently isn't handling new registrations).
• Erik Sink announces the release of Vault 2.0 which includes a free Single User Edition.

Some random notes from last night's Tuesday Extreme Club:

• Jamie Cansdale, an all-round very clever guy, came along for the first time and got a chance to receive thanks from many of the people that had used his NUnit Addin. We had a great chat about Mono, Rotor and the strengths of .NET being a formal standard as well as having a share-source implementation.
• Joe Walnes from ThoughtWorks about message-oriented development, the decorator design pattern, how Aspect Oriented Programming could be thought of as generic decorators.  He also spoke of his joy after achieving his life aim of becoming the owner of a blow-up a bouncy castle (apparently only £250 including generator)
• Joe also mentioned Prevayler that basically removes the need for a data store with projects that use less than 2GB.  The simple idea is that the entire memory space can be persisted to disk.  Each action performed on the model uses the Command pattern to write out a transaction log that can be replayed if the system goes down between persistent writes.  This allows for easy replication of systems between machines as well as meaning that programs don't need a database.  A very simple, but potentially powerful idea.  For small applications, do I really need to struggle with a database, or could I manage it with in-memory objects?
• Tim McKinnon told the story of the invention of Mock Objects. The Pragmatic Programmers have a useful list of 7 reasons why you would want to use Mock Objects. For Steve, the most important was being able to test relationships between objects.
• Tim gave a great overview of the problems with Visual Studio .NET.  Basically it takes to long to locate the right piece of code. His question was why can't use hyperlinks to navigate around the code (Reflector does this brilliantly) or even a Find Type dialogue box that allows you to type in the name of the type you are looking for with IntelliSense.
• Chris Stevenson was at his last meeting before doing the 'reverse-outsource' and moving to India to join the ThoughtWorks team there.  Can't wait to read about it in his blog.

Roger Session's latest ObjectWatch newsletter relates planning a SOA implementation to thinking about how pilots win dogfights.  The moral of the story - iterative development is a winning idea:

"Boyd [an Air Force Colonel who thought about winning dog fights] teaches us that we win by iterating faster than our enemy, not by building a more expensive plane than our enemy. We will do better by implementing and deploying a small piece of the SOA, getting it right, showing its value, learning from the result, and then iterating on to the next piece."

The benefits of iterative development is an idea that keeps coming back to me from multiple angles.  It was the key idea I took away from a recent 3-day training course on the Microsoft Solutions Framework.  It's one of the key principles from Lean Development and from the XP's idea of iterations.

At last night's Extreme Tuesday Club meeting we talked about the use of Gold Cards as a way of handling problems that can arise in successful Extreme Programming teams.  The idea of Gold Cards was presented in this paper from XP Universe 2001 which came out of the original Connextra team (an early and influential London XP team).

When an XP team is functioning successfully and doing paired programming, frequent releases and working at a constant it can be difficult to find time to do individual investigation on new approaches to problems.  There are several difficulties for a successful XP team:

• It can be difficult to take time out and think about new and innovative approaches to a problem.
• Often innovative new ideas come from individuals thinking laterally rather than a team focussed on task completion.
• Sometimes pairing and the team work made it hard to highlight positive contributions of individuals, or to handle performance reviews.

The Gold Card was a way of overcoming these problems.  The index card is a core part of XP planning, used to write User Stories and drive development.  The Gold Card is simply an index card that allows a developer to spend some a day of solo time investigating a topic of their choice, ideally with some business benefits.  They used this system:

• Each developer had two Gold Cards each month, so about 10% of work time.
• During the morning stand-up meeting a developer could elect to use the Gold Card
• The developer writes on the card what they want to achieve and provides an update at the next morning's stand-up meeting as well as on the Wiki.

Part of the discussion last night was how one global financial bank allow their developers to do skunkworks style tasks on Friday afternoon.  Gold Cards provide a mechanism for time-shifting this idea.

Gold Cards helped promote a 'praise culture' within the group.  It also proved a successful motivation tool.  On top of this there were significant business benefits, such as reducing project risk, increasing development efficiency and most surprisingly, generating a business opportunity that became the company's major product.

Mary and Tom Poppendieck's have a book on Lean Software Development that's really excited me of late.  I was reading it while I was thinking about how the project I just finished on could be improved in future iterations.

Lean Software Development takes ideas from Lean Manufacturing can be applied to software development.  Their website has an excellent range of presentations and publications.  The one I first read, which I think is as good as the book, is 'The predicability paradox'.  It goes through their eight keys to lean thinking:

• Start early. Focus on establishing good communication between the group and about the problem.
• Learn constantly.  Look for end-to-end slices of functionality that you can build, test and deliver to learn more about the problem.
• Delay commitment.  Use encapsulation, loose coupling, refactoring and automated testing to make it easier to change code.
• Deliver fast. Focus on being able to deliver fast (e.g. automated build and deployment) through excellent operational discipline (source code control, build tool) in order to get quicker feedback.
• Eliminate waste.  Focus on customer value and remove wasted processes.
• Empower the team.  Avoid central control, focus on self-directed workers.
• Build integrity in.  Write the tests at the start.
• Avoid sub-optimization. Sometimes breaking a complex task into small parts leads to sub-optimum solutions.  Make sure you measure the right things and set the correct goals.

For some reason this just seemed to speak to me in ways that some of the other writing on Agile/Extreme hasn't in the past.

Steve Maine has a post on using a Gantt Wall to manage projects: it's big, visible, lo-tech and easy to manipulate and change.  I think it's a great idea in line with the XP/Agile spirit of getting away from traditional, rational (time and motion) style project management tools in favour of simpler approaches that are more likely to work.

I think MS Project style Gantt charts are useful, but too often they form part of a projects Death March when they are never updated.  Initial estimates of features become prison sentences for developers since they become set-in-stone.  Weekly meetings are focussed on how far behind developers are from their original estimates.  The whole project becomes burdened with the fact that it's slipped, is late or behind.  This is where lo-tech idea's like the Gantt Wall are so useful.  As Darrel Norton says:

the visible wall-Gantt is more than just a Gantt chart, it builds morale, serves as a social focal point for the team, and allows the celebration of success on a daily basis.  Until we can digitize all that, the low-tech solution will continue to reign supreme.

My Favourite Project Anti-Pattern
All of this makes me think of my favourite project anti-pattern which is to simply avoid dealing with any problems on the project and force everyone to work as many hours as possible each week for the length of the project.  It doesn't make the project any more successful, but it certainly saves having to deal with anxiety that can come from admitting and dealing with the situation where the project is off the rails.  When it comes to the deadline for the project, the work may not be done, but the excuse is difficult to refute: 'could we have worked any harder?'.

Roy's at it again, campaigning for IntelliJ and asking Visual Studio to take notice and compete with the advanced developer experience provided by the IntelliJ IDE:

 "I felt like I was not coding alone ... if you decide you should have a new method ... you just type the method name and provide its parameters if necessary.  IDEA will prompt you with an unobtrusive popup with a suggestion to create a new method ... the method will be created in the corresponding class with the proper method signature (including correct parameters), so that you can implement it later"

I saw the same feature demoed by Erich Gamma, (the G in the GoF Patterns book!) when he came to London to talk about Eclipse.  I was so impressed the hairs on my arm stood up.  Forget clapping at the PDC, you know a feature is good when your body reacts with goose bumps.  As I mentioned in a previous post about refactoring, I think this feature would solve a lot of the frustration that Randy mentioned where Visual Studio's Intellisense clobbers any new methods or properties written in tests before the object exists.  It's the difference between thinking of the IDE as a text editor and thinking of it as a developer tool.

Luckily, IntelliJ are developing an IntelliC# add-in for Visual Studio that will bring its intelligence to .NET.  I can't wait to get it.

As Roy laments, what's Visual Studio doing?  I remember the glory days, back when Jim McCarthy (of Dynamics of Software Development fame) was working with the Visual C++ team making the IDE great.  Where's the passion, the spirit, the sense of competition gone?  For all the talk at the PDC there was noticeably little about Orcas, the Visual Studio version after Whidbey.  Visual Studio is good, but it can be even greater.  Let's hope that good things are in store.

Some ThoughtWorks experience with TDD and Refactoring
Dan North, a ThoughtWorker, has an article in the Java Developers Journal called Test-Driven Development Is Not About Testing,  his major point is that 'it's not about the tests; it's about seeing how little you actually need to do and how cleanly you can do it!'  Jeremy Stell-Smith, also ThoughtWorker, has a reply post TddIsOnlyOnePieceOfThePuzzle where he makes the following statements about TDD:

• TDD is a tactical thing.  It helps developers from adding unnecessary complexity and allows them to think about how the code will be used before other developers use it.
• It's important to refactor while using TDD to reduce duplication to keep the system clean.
• If a system has good automated testing and loose relationships between classes, then tests can give good feedback about the extent of damage that a change to the system might bring.
• Tests work best when they test small isolated areas of functionality that shouldn't break if anything else changes.  For this reason, unit tests are easier to manage that end-to-end integration tests

There are also some points that Jeremy makes that seem a bit 'religious' such as 'changing your mind later is about as expensive as changing it later'.  This just doesn't seem rational, but perhaps I'm just arguing for a shades of grey rather than this black and white style statement.  I know that TDD makes it easier to make a change, or to measure the impact of a change, but it's still better to make changes as early as possible because it is more expensive to make changes later.  However, I think that his assertion that 'tests must be as fine grained as possible so that most changes no matter how radical don't affect many tests' seems a fine goal, but is hard to achieve.

Early Microsoft experience with TDD
Chris Anderson points to Randy, a friend of his within Microsoft who's reflecting on his experience with TDD.  Randy says that it takes a lot of discipline to stop writing code before a test case that uses it and that Visual Studio is a hindrance when working test first because the intellisense stops being helpful when the writing test code for methods that don't yet exist (Roy wrote a good post showing how IntelliJ handles this situation in a much cleverer way, hopefull Microsoft will pick this up and copy extend it).  Randy also talks highlights how TDD can be difficult:

 ... it's a completely different ball game when you're changing the behavior of code as opposed to writing entirely new code. Say you've written a sizable body of code with inter-related classes and non-trivial implementations of whatever. Now suppose you want to make a fundamental change to one of the more central class's behaviors ...  substantial build breaks where methods no longer exist, because the functionality they provided has been made unnecessary ... doing test first in this case is tricky. You can start by changing the test that exercises the fundamental class in the new way, and then changing the fundamental class to pass the test. Unfortunately, then you've got build breaks across your entire project, and fixing those involve work that should also be done in test-first fashion. The way I did this was to exclude all the other files from the project, get the fundamental tests working again, and slowly re-introduce the other functionality, tests first of course, fixing/updating as I go. Maybe it's the same amount of work in the end, but it feels more cumbersome

From my experience and the developers I've talked to at the Extreme Tuesday Club, if the code is difficult to test then it can highlight weaknesses in the design of the code (such as it being too tightly coupled).  Put another way, designing code with testing in mind often leads to code that is better designed.  The pain that Randy highlights when working with inter-related classes encourages a designs that are more loosely-related so that they can be more easily tested. 

Mock Objects is an approach to making testing easier in large complex systems.  As the authors of the definitive paper on Mock Objects say testing can improve code "by preserving encapsulation, reducing global dependencies, and clarifying the interactions between classes."  More on that in a future post.

I spent the mornig in the Microsoft Pavillion in the Expo hall.  There are real live Microsoft architects and developers available to chat with.  There were more Microsoft staff than delegates, so I took the opportunity to chat with James Newkirk who works for the Patterns group.  He is also the author of NUnit, so I feel a debt to him for the joy that the 'green bar' has brought to my life.  Steve Maine was wondering whether James is now a Microsoft employee, and I'm happy to say he's joined Microsoft to help bring Test-Driven and Agile ideas to the world of .NET developers (he didn't say that, but I'm joining the dots here).  He's writing a new book Test Driven Development in Microsoft .NET that will be released next March, there was a sample chapter available in the Pavillion.  Here are some of the points that came up:

• He's not a fan of Mock Objects because he thinks that in general they are too complicated and don't pay back the investment required to use them.
• The book goes through how to use test-driven development on n-tier applications.  To test the database they decided on using ADO.NET DataSets.
• One pattern to use when doing test-driven development against the database is to use transactions.  In the startup of each test a transaction is started, then in the the completion of the tests the transaction is rolled back.  This saves polluting the database with test data and is quicker than waiting for the database to clean itself up.
• The patterns group are going to create new .NET sample applications that demonstrate the practices and good architecture.  The Duwamish Books example was driven by the desire to demonstrate features rather than architecture.  I'm looking forward to seeing what they come up with.
• We spoke about the work of Gregor Hohpe's new book Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions.  Gregor has already contributed to the MS Patterns group on Enterprise Solution Patterns with Microsoft .NET.  James said it's likely the Patterns group will pick up more of Gregor's work on in future.
• I pulled out my laptop and spoke about the brilliance of Reflector.

Steven Maine describes a war story from a colleague about a client-run project using XP Methodologies.  It's a useful warning about the dangers of doing XP without understanding or using all of the practices.  The project Steve's talking about have been going 10 weeks with no releases and 'since the customer is using these so-called “XP methodologies”, there’s no hard and fast documentation as to what the agreed upon scope actually is.' 

In the XP Refactored: The case against XP the authors mention that one of the problems with XP is that it is a high-discipline methodology in that all of the core 12 XP practices need to be implemented if the project is to be successful.  I think the bigger risk with XP is that it's an excuse for crazy style project management (think glorified cowboy coding).  XP is not a methodology that validates projects that have no methodology.  For example the idea is not 'don't do any documentation', it's 'just do the documentation that it necessary'.  I'm not sure that any (sane) person would advocate not having some written form of customer requirements (even if they are just 3 x 5 index cards on a wall).

In the project Steve mentions there's no mention of any of the practices actually being used.  As he identifies:

XP might be great in theory but often times has issues with practical application. However, most horror stories I’ve heard that involve using “XP methodologies” are in fact about problems that stem from using “mostly XP” or “sort of XP”

Steve suggests that focussing on releasing to the customers is an important concept that would have reduced the risk of scope creep.  I agree that it's a good practice, but there's also the concept of the Planning Game, User Stories and the idea of project velocity.  Yesterday I found this  presentation from on how the BBC's interactive TV group used XP/Agile practices to negotiate the scope of projects.  Basically they tracked the project's velocity - how many user stories were being completed each week.  They estimated the cost of the features the customer was asking for and when it was clear the features were too ambitious they re-negotiated.   This is the same concept as principled negotiation that Steve McConnell mentioned years ago in his book Rapid Development

Hopefully this lack of understanding about XP wont rub off on the good ideas that the methodology advocates (especially test first development).  As the software reality site mentions:

Agile proponent Alistair Cockburn describes XP as a "high discipline methodology". In a discussion on the Wiki web, he also suggested that most teams that say they're doing XP don't actually do all the practices.

As XP increases in popularity and hits the mainstream, more and more teams will attempt XP, probably without a clear understanding of what is really involved. They will most likely be drawn in by XP's "low discipline" practices (such as no big up-front design and minimal documentation), but without applying the high discipline practices that act as an essential safety net (such as unit testing, pair programming, collective ownership and constant refactoring).

Alan Cooper introduced personas as a user interaction/product design technique a few years ago.  Here's a good definition:

"A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns are well understood—you can satisfy the broader group of people represented by that archetype." 

They are a very effective method of getting developers to focus on a particular person when building software, rather than a class of user (e.g 'How would Steve the crazy trader use this trading screen', instead of 'What features does a trader want?').  Microsoft have been a keen adopter, especially in the core Windows group as this presentation highlights (they go to the point of developer posters and even a live email account for their personas, and rate product features using a feature-persona priority matrix).

What I hadn't realised until recently was that they are using personas in the Visual Studio group.  They are often backed up by more hard-core usability work (such as this presentation BradA mentions on Describing and evaluating API usability at Microsoft). Walter Moise, a contract developer with Microsoft, writes about the personas:

"Every group has personas. In the developer tools, we have Mort, Elvis, and Einstein. These guys are respectively, the typical VB developer, the typical C# developer and the typical MC++ developer. We have a detailed description of them in very specific vivid detail, which include not only the relevant job habits, but also their lifestyles (how they have fun, what they do on weekends). These get very specific, that you wonder if they are talking about a real person.

Mort is your most common developer, who doesn't have a CS background, may even be a recent newcomer, and doesn't quite understand what the computer is doing under the covers, but who writes the dinky IT programs that make businesses run. Elvis, more knowledgeable, cares about code quality, but has a life too. Einstein writes some serious-ass piece of code like device drivers, wants to get things done, needs to be able to go low level and high level, needs a language without restrictions to get his job done."

Mort seems an unfortunate name for the VB.NET developers.  I can't imagine anyone aspiring to be a Mort.

I find it interesting that there isn't much talk of personas within the XP/Agile world.  The agile processes are 'people friendly' but this is mostly if those people are developers.  Admittedly personas may have more impact on consumer shrink-wrapped applications, but I believe that the investment is still worthwhile in enterprise software projects (it's not a big investment for the potential pay-back).  There's still a lot (too much) responsibility placed on the client representative to know what the clients actually want.  Personas seem like an incredibly easy, but powerful tool that would fit well into the XP/Agile arsenal and help ensure that what the developers built is likely to "delight the customer" (to steal Steve Balmer's phrase).

Continuing the theme of what the .NET community can benefit from the Java community comes news there will be a version of IntelliJ for C#.  IntelliJ is regarded as the best Java IDE by many people. Here's Martin Fowler's response:

"I know lots of ThoughtWorkers who are dying for this tool. While Visual Studio has a lot of nice features, the programming capabilities seem primitive when you've used a tool like IntelliJ or Eclipse. Of course, I find I really miss the refactoring capabilities, but there's much more than just the refactoring that makes IntelliJ such a stunning tool. Having a tool like this as a plug in to Visual Studio will make .NET programming much better."

I also noticed today that Martin Fowler is coming to the PDC to be part of an architecture discussion panel on What is Service-Oriented Analysis and Design?

Larry O'Brien suggests that Microsoft and Microsoft developers look at what they can learn from the Java community.  The key point for me is when Microsoft will support proper refactoring tools within their development environment.  Martin Fowler, who wrote the first major book on the topic, defines Refactoring as:

“…the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”

When combined with the practice of Test Driven Development (supported by automated testing frameworks like NUnit) Refactoring is an essential tool in any developers tool kit.  If you take the position that software development is a craft then Refactoring is like a painter discovering a new type of brush, or a carpenter discovering a new type of hammer.

The Eclipse project, an IBM backed project to develop a new IDE, they have superb support for refactoring, as shown on their help page.  While there are products available for .NET such as C# Refactory, they are still too buggy to use reliably.  I'm hoping that we'll be seeing the addition of Refactoring to Whidbey at the PDC.  Actually, after Googling on it I found that Alan Dean, fellow UK-based Microsoft Developer and PDC attendee has done the hard work of reading the PDC abstracts which state:

Visual C# "Whidbey" includes improvements to the code editor and debugger that cater to the code-focused needs of the C# developer. With support for refactoring in the code editor, advanced visualizations in the debugger, and more, Visual C# "Whidbey" supplements its modern syntax and component-oriented features with new and powerful productivity-enhancing IDE features. Source

The other point that I enjoyed Larry's article was that Java and Open Source have a much better sense of community:

With GotDotNet and other sites in "The .NET Code Wise Community," Microsoft’s presence is palpable and can be somewhat stifling, like a sanctioned school event where the principal is sitting in a corner reading a magazine.

This is definitely something I notice when visiting the Extreme Tuesday Club in comparison to the Microsoft User Groups.

Here are the presentation slides from my Test First Programming with .NET talk at the .NET London user group.  As I finished the talk, where I was demonstrating the Nunit and the NUnit Addin when the organiser said the guy who wrote it, Jamie Cansdale, was in the audience.  Talk about the choir preaching to the minister!  Luckily Jamie is a really nice guy.

We had a chat at the pub afterwards where Jamie said he understood my concern that the Nunit addin didn't have the 'green bar' of the original GUI.  He lamented that his girlfriend didn't really understand the work he did (a common problem in development), but that she did understand the green bar.  In my talk I shared that both my wife and mum know about the green bar.  I compare its affect to the sound of a bell to a Pavlovian dog. Jamie said he'd had to switch back to the GUI after the addin broke when Nunit was upgraded, and it made him realise he missed the green bar as well!

The good news is that Jamie's working on a way to provide a view of the tests inside Visual Studio, so as part of these changes we may see the green bar appearing in the Addin.

Here's a book that looks interesting: Extreme Programming Refactored: The Case Against XP (courtesy of Mehran).  It seems to be based on an article availabe on the Software Reality website. I think its a positive step to see some critical reflection on XP, as I've had too many conversations about XP that sound like religious discussions.  I've ordered the book, but based on the article it looks pretty funny and as if it has some interesting points (can a customer afford to let a good person spend 100% of their time with the XP team?  How does pair programming allow a developer to think and reflect and achieve a state of flow necessary to understand some problems?).  Should make the next Extreme Tuesday Club meeting interesting ...

I had an enjoyable day today working alongside Mark White, a consultant (and all round clever guy) at Microsoft in the UK.  Amongst other topics, Mark asked me a great question about the difference between Extreme Programming and Agile Development.  I said that I thought the fundamental difference was that XP was based on a more prescriptive set of practices (Test First, Planning Games, Paired Programming etc) whereas Agile Development was more a philosophy (based on focussing on the people issues of software development and doing things that worked).

At a drinks event tonight I spoke with a developer from ThoughtWorks who backed up my idea.  He said that one of the challenges was that Banks and Finance companies didn't like the idea of doing anything 'Extreme' so Agile was a better way of describing it.

I was interested to hear though that ThoughtWorks mix their Agile approach with large-scale multi-national development.  As the Agile Manifesto says, an Agile approach is about individuals and interactions over tools and process and customer collaboration over contract negotiation.  One of the key points of XP seems to be about communicating and talking with people, both within the team and between the team and the customers.  It strikes me that these principles may be challenged by large-scale projects worked on by geographically disburse teams (even if, as the ThoughtWorks developer said 'they are all clever people').

I also think there are great challenges with doing an XP approach on large teams.  In order for this to work I believe there has to be an overriding architecture that lets the large project act like lots of small teams.  To me large-scale projects with teams in different countries make it very difficult to practice agile or Extreme Programming.  Still, it's interesting watching ThoughtWorks as a test bed for Agile methods on large scale projects.

Mark also mentioned that the Microsoft Solutions Framework (framework, not methodology) could still add something to XP or Agile approaches with it's notion of the Team Model.   I particularly agree that these approaches could be improved with the role of Program Manager, but perhaps that's just my bias.

I've spent more time this week installing components I've worked on with a team who are using them in their project.  This is a team of Java programmers who are moving across to .NET.  It's been interesting to see how difficult they are finding it.  Most of the problems are down to the way IIS/ASP.NET handle security on boxes that have been locked down, and the complexity of their configuration files (we spent 2 hours on a problem due to a typo in a type name in one of the configuration files).

On the security permissions, I think it's excellent that Microsoft ship their operating systems in a more locked down way, but if you don't educate developers about what is going on then what tends to happens is suddenly the Everyone user and other important users get permissions like 'Full Control' over the entire hard drives. 

On the config files,  I remember Alan Cooper mentioning how only an engineer could have designed a computer keyboard where potentially pressing one key could change/invalidate the actions of all others.  It's like that with the config files - they are really powerful, but a single mistyped character can stop the whole system from working.  It would be better if there was some way of viewing the information (e.g. WSE 2.0 has a nice Dev Studio plugin that presents a UI for the config file), validating it, or at least easily separating different classes of information (e.g. a mistake in my logging configuration is less critical than a mistake in the user account that ASP.NET runs under).

After accepting the need for greater education and improved design, I think that the attitude of developers plays a key role in dealing with these issues within a project.  It's interesting how one person's feelings of frustration, negativity or anxiety can sweep through a team.  For example, I was trying to solve a problem to do with security access and had someone sitting next to me saying 'this is crazy, this is way to difficult ...' which made it very hard to focus on solving the problem.  When the issue was finally resolved there was more talk about how ‘stupid’ the system was than on making sure they understood why it occurred and how it could be fixed in future.

One particular danger in teams is 'magic' or 'superstitious' thinking - the bafflement when something that wasn't working is fixed.  This can lead to a feeling of hopelessness within the team - 'It wasn't working, then we did lots of things and now it just started working again but I don't know why'.

Getting over the feeling of hopelessness is key.  The starting point is to work from the assumption that nothing magical is likely to go on.  When the feelings of anxiety start it's important to focus on letting these go and focus on through the problem rather than worrying about the position you're in ('damn, I need to get this working now').  It's important to work on a model for understanding the problem - describe how you think it should be working, look for areas where this might be wrong and propose hypotheses about what's going on. Also, avoid stating the obvious 'we're stuck and nothing we're doing is working'.  Finally when things work again it can be worth backtracking to break them again in order to understand exactly what solved the problem (e.g. after overcoming the security problem we spent some time reproducing it just to make sure that our solution worked and our understanding of the problem is correct).

Unfortunately, working on development projects is harder than it should be.  It requires a lot of knowledge and education to get things to work sometimes (which is why we can ask for the large salaries).  Attitude plays a large role in how smoothly a project runs.  It’s important to avoid feelings of panic and anxiety and hopelessness by focussing on understanding problems and learning more about how it is working.   Then on the larger scale, campaign Microsoft to improve user education, event viewer messages, configuration tools and tools that make it easier to problem solve what’s going on at the lower levels.

I had my code review today.  After preparing hard for it, it went well.  We found one area where I wasn't handling all of the boundary conditions as cleanly as I could and another area where I'd overoptimised a loop and thrown readability and maintainability out of the window.

On the one hand, it's annoying to have someone else find a hole in my code, on the other hand, it's good to have found it and to have learnt something about how to make code better.  I'd trade the anxiety about 'opening my kimono' for the benefits of improved code and the learning opportunities any day.

Some of the 'learning points' I got from the exercise include the benefits of drawing a diagram to make a problem clearer.  We drew a matrix of possiblities for certain end conditions, then went through cell at a time and worked out what the outcome would be.  I'd initially tried to do it in code comments and had missed some of the complexity.  The other thing I appreciated was being able to bounce ideas of another person.  My dream is that XP practices and pair programming would result in more interactions like this.

Tim Bacon has another good post on his blog about the techniques someone playing the coaching role in an XP team can use to persuade, influence and help other team members.  Similar to the idea of a Project Manager at Microsoft, Tim notes that an XP Coach often has responsibility without authority.  Tim's list is comprehensive and insightful and covers many of the techniques I studied in counselling psychology topics at University. 

I like the fact that he pushes using open ended style approaches rather than more didactic approaches.  Using more of a Socratic approach is a much better way of encouraging people to grow and develop in intellectual pursuits like programming.  I'm sometimes surprised by the level of posturing, ego and insecurity amongst many IT professionals - a lot of energy seems to go into defending a position of expert rather than into producing results or helping others with their knowledge.

It's encouraging to me that there are people like Tim out there who are focussed on using good communication techniques to help other developers achieve their potential.  It's interesting that he mentions listening is a key part of this.  I think it is a mistake that some developers believe that gruffness or snap-decisions are better than reflection, questioning and thinking.  I'm interested to know how Tim views the difference between the activities an XP coach might perform and those of a mentor.  I know on Tuesday night we spoke about one difference being that as an XP coach you also have to be a performing member of the programming team in order to garner the team's respect (through 'having skin in the game' in the words of Alan Cooper).

In browsing around tonight I also found an excellent blog entry from Morris Sims a Microsoft Employee on doing what you love.   He mentions the importance of having mentors that adapted to his strengths and weaknesses, making a bet on yourself and taking risks.  Ed Kaim also adds to this the idea of 'just doing it'.  I'm certainly taking this to heart at the moment getting out there and presenting to the developer community and extending my contacts.  I'm presenting on WSE again to a group in Manchester next week.

In other news, I had a great time today working with another developer to integrate work I had done into their project - it was another experience of pair programming, sharing knowledge, working efficiently and getting things done.

Last night I went to another Extreme Tuesday Club (XTC) at the Old Bank of England pub in London.  I've been attending for the last few months and the club's been going for over four years.  It's a free event open to anyone interested in extreme programming or agile development.

It's one of the most interesting and intelligent groups of developers I've met.  I know a lot of people might be turned off about a bunch of programmers talking shop in a pub.  However, I find that when people get together and share a passionate it's very exciting and interesting.  It's quite comon to see people pull their laptops out and start programming.  Many of them are active in the Open Source community - a great line I overheard was "sorry guys, go to go - I have to do some Open Source".

The people differ in their range of experience with XP programming.  Some members hold PhD's in Computer Science and have been doing XP since it began, others have read some books and want to know more.   In the past few months several key international figures have also dropped by including Martin Fowler, Erich Gamma and Alistair Cockburn.

Here's an indication of the kinds of topics I talked about last night:

• The strengths and weaknesses of strongly-typed and weakly-typed languages.  What are the relative merits of Ruby and Python? I also got my first insight into the 'two axes of typing - strong versus weak, and dynamic versus static'. Dynamic languages let you assign a value without declaring the type of the variable first (such as Perl and Python).  Perl is considered a weakly typed language because you can put another value type into the variable, whereas Python is a strongly typed language as it will only allow values of the original type,
• What does involved with the concept of a Coach in XP?  Should there be a designated coach in each team or should everyone try and help any other team member in difficulty?  The notion is that coaching is a process not a role.
• I met Tim Bacon, who bills himself as an XP coach, for the first time after reading many of his postings.  It was fantastic to hear someone else involved in programming talk about how 'emotions are what interest him most'.
• Sometimes the role of a coach can be to listen to someone and validate them, listening to their anxieties: it can be difficult to talk on this level to the managers or team leads.
• How to handle a situation where the project's success revolves around one key individual.  This was referred to as the 'Bus Test' - how many developers would have to be hit by a bus before the project was in trouble.  We discussed a situation where a key devloper had been removed from a project in order that the team and the project continue more successfully.
• Does a team celebration negatively impact future performance?  One group had recently delivered their project and had a day on a yacht as a celebration.  Their manager had challenged them - was the day of team building successful since their performance in the weeks since had been lower than before.  One point of view was that it wasn't the effect afterwards, but the motivating property of the reward prior.  Others felt that it was the motivating quality of the reward in the eyes of the other teams in the company.
• A discussion on Refactoring and the GOF books have made a significant contribution to the developer community.  Refactoring was really about the practice of what programmers do everyday.  Someone described it as like learning how to cook properly after years of reading a cookbook.  It's like if you are a brick-layer finding out there are different ways to lay bricks.  The benefit of the refactoring approach is that it is language independent - it's about why you do something. One of the most useful ideas in Refactoring is the notion of smells - a sense that the code has some problems. 
• A general complaint from many of the members moving from Java into C# is that Microsoft doesn't have good support for refactoring in C#.  The belief is that Microsoft are interested in the Visual Basic style developers who want to have GUIs and Wizards that help them achieve tasks.

All up a fantastic evening in the pub.