• Mike Hadlow: Enterprise integration with MassTransit, October 1st
• Dylan Beattie: The future of Web development: HTML 5 and ASP.NET MVC 2, November 2nd
• Toby Henderson: Introduction to Mono, December 3rd

All these events are free, but up-front registration is required for capacity planning. Click on individual events to register.

In addition to that, I’ll be running the 3 day Progressive .NET course again on November 11th-13th. The course helps students learn the most important emerging practices in the .NET community such as dependency injection, aspect oriented programming, MVC, object-relational mapping, unit and acceptance TDD and so on, with practical exercises using leading opensource .NET tools such as the Castle stack, NHibernate, MBUnit… For more information and to register, see http://skillsmatter.com/course/open-source-dot-net/opensource-dot-net-tools-crash-course.

Space-based architectures are an alternative to the traditional n-tier model for enterprise applications. Instead of a vertical tier partitioning, space based applications are partitioned horizontally into self-sufficient units. This leads to almost linear scalability of stateful, high-performance applications. In this presentation, I’ll talk about space based programming in general and demonstrate how to do that on the .NET platform.

The event is free but up-front registration is required. See http://skillsmatter.com/podcast/open-source-dot-net/space-based-programming/ for more information and to register.

Increasing visibility

A common topic in the discussion was increasing visibility, both the visibility of business value to developers and visibility of developer progress to business. We discussed different metrics to increase visibility of the progress, but this turned out to be quite a tricky subject. One interesting metric mentioned was cycle time, how much it takes to get a story from the backlog into production. This would require that stories have a fairly normalised size though. The conclusion for me is that metrics make it very easy to slide towards efficiency but not effectiveness (with the example of a hamster in a cage which might spin the wheel very efficiently, but going nowhere), which also lead us to the fact that teams should be aware where does the value come from and define what success looks like before a project starts. Ensuring that everyone knows the answers to these questions would significantly increase the value visibility and help people prioritise better.

Some interesting examples of what companies do to increase visibility were estimating technical debt with monetary value (how much will it cost to fix it) and assigning monetary value to stories (how much benefit will it bring) and implementation estimates (how much will it cost to make it). Although everyone agreed that getting these figures right would be a challenge, even rough estimates can help immensely to set the priorities and ensure that we’re building the thing of greatest value.

Another challenge mentioned is actually measuring how much value features bring when they are in production and do they justify the cost of maintenance. We all agreed that it is very hard to measure effects of individual features, but A-B testing was suggested as a way to to measure this. In A-B testing, a part of the system runs with a feature and a part of the system runs without it, and then the results are compared to determine the effectiveness of that particular feature. This approach has additional management overheads and risks involved though.

Waste

Unsurprisingly, the discussion often touched upon lean software development principles and looking at what causes waste in the process. Two good books mentioned about this were Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck (ISBN 0321437381 Addison-Wesley 2006) and Agile Management For Software Engineering by David Anderson ( ISBN 0131424602, Prentice-Hall 2003). Anderson is also apparently working on a new book related to this subject. Additional suggested resources for Lean Software development included Lean Conference 2009 videos, David Anderson’s blog , Karl Scotland’s blog , David Joyce’s blog and the Agile in action Blog.

A common theme in the discussion on waste was building too much software, where people did not know whether they really needed it. As a possible solution for the problem we talked about the DDD core domain idea, where companies should focus on identifying a very small core of the system that makes it worth building, something that brings direct competitive advantage, and source the rest from external providers or buy off-the-shelf solutions. Core domain is explained more in Domain-driven Design: Tackling Complexity in the Heart of Software by Eric Evans (ISBN 0321125215, Addison-Wesley 2003).

Another source of waste was building “nice to have” features suggested by the business but not really bringing any value. As a possible solution for this, we talked about the Goals-Features-Requirements breakdown (a variant of which is Goals-Stories-Acceptance tests) where each feature introduced into the system has to be connected directly to a stated project goal, and each requirement has to be directly connected to a feature. If the person suggesting a requirement cannot name a feature (or likewise someone suggesting a feature cannot justify it by naming a goal), this gives us ground to push back and reject scope creep. This idea comes from The Art of Project Management by Scott Berkun (ISBN 0596007868 O’Reilly 2005).

The development counterpart of this is just-in-case code, something that developers decided to put in because they think it is needed. This was called the biggest source of waste by Mary Poppendieck in the Lean Software Development book. As possible solutions for this, we discussed specification workshops and agile acceptance testing – explained in my book Bridging the Communication Gap Specification By Example and Agile Acceptance Testing (ISBN 0955683610, Neuri 2009). As the answer to the problem ‘we know that we’ll need it soon’, we discussed a fine line between making the system flexible to accept a future change and actually building in flexibility. The former would involve isolating a piece of code that we know is going to change, the latter would involve actually building in a very flexible framework to start with. The conclusion was that very often these complex flexible frameworks don’t pay off as requirements might change and the requested flexibility never actually makes it into the product.

The fourth related cause of waste was working on a problem that people don’t know enough about and identifying that too late. Specification workshops are also a solution for that.

UI design and redesign was also perceived as a common source of waste, perhaps because all the people in the room were developers. Someone suggested Yahoo’s UI design pattern library as a good source of information to make this process quicker and easier.

Prioritisation

The last major theme of this discussion was prioritisation – how do we actually decide what to build first and how to deliver value quickest. Value visibility certainly helps, and assigning monetary value to features and costs of production might help prioritise. There was a concern though that only low-risk features would ever get implemented by this, but we concluded that this would probably be pushed back to the business and they would be able to decide how much risk they want to take.

We also discussed the difference between iterative and incremental development and how that helps with prioritisation – rather than asking customers to prioritise between a car door and an engine, for example, we could ask them to prioritise between a car with a poor door system but a great engine and a car with great doors and a poor engine, delivering a car that they could use in any case. This is explained in a lot more detail by Jeff Patton (also see Alistair Cockburn’s response and my write-up of Patton’s keynote at XPDay 07).

Having a map of goals to stories and tests makes it easier to prioritise as well, because business should be able to prioritise goals and we can derive priorities of lower levels based on that.

• A Set of Unit Testing Rules, article by Michael Feathers
• Red-Green-Refactor, article by Jim Shore
• Mocks Aren’t Stubs, article by Martin Fowler
• The Decline and Fall of Agile, article by Jim Shore (rescuing Scrum Teams).
• Original TDD as if you meant it exercise
• TDD as if you meant it exercise repeated at Alt.NET UK day one
• xUnit Test Patterns: Refactoring Test Code, Gerard Meszaros, ISBN 0131495054, Addison Wesley 2007. Also see the accompanying web site.
• Exploring Requirements: Donald Gause and Gerald Weinberg, ISBN 0932633137, Dorset House 1989

Many of these ideas are explored in more detail in my TDD in practice course, which will start from September at Skills Matter.

The exercise involves developing a very simple piece of code strictly adhering to the TDD rules, so much so that participants aren’t allowed to create domain methods or classes other than extracting them from test code. The goal of the exercise is to demonstrate factoring out just what you really need from the test code into domain design rather than starting with a pre-set design structure. Although this is in general taken as a goal of TDD, many programmers (me included) don’t realise how much their assumptions make them jump ahead too quickly. By making it very painful to add new domain code, this exercise slows participants down to a point where people have to spend a considerable amount of time actually focusing code on exactly what is required and no more.

Even on a very simple problem such as tic-tac-toe, differences from a pre-conceived design and the one that emerges from code are considerable, the latter being a lot more elegant and better suited to describe a problem.

The exercise

The original exercise involved stones and the Go game. As I’ve never played that before and we had a lot less time than in the original one, I suggested tic-tac-toe. This turned out to be a very good idea as we spent less time explaining what the domain but it still proved the point of the exercise.

The requirements on the flip-chart were the following:

• a game is over when all fields are taken
• a game is over when all fields in a column are taken by a player
• a game is over when all fields in a row are taken by a player
• a game is over when all fields in a diagonal are taken by a player
• a player can take a field if not already taken
• players take turns taking fields until the game is over

The dynamics

All the participants worked in pairs. Most of the teams started by building a 3×3 board and describing requirements that were not given at all (eg first player won, tics or noughts being placed) and took three or four attempts at describing the problem to really go down to basics. As predicted, people were annoyed by this but I did make an effort to explain that the start of the exercise feels silly and annoying so this went much better than I expected. After the first requirement was done correctly, the next three followed easily as they are fairly related. The fifth one though posed a problem again and this is where things got really interesting, some teams falling back on the grid idea (and getting their code deleted) and some teams starting to flesh out the concepts of players and the actual dynamics of fields being taken.

By the end of the exercise, almost half the teams were coding towards something that was not a 3×3 char/int grid. We did not have the time to finish the whole thing, but some interesting solutions in making were:

• a bag of fields that are literally taken by players – field objects start in the collection belonging to the game and move to collections belonging to players, which simply avoids edge cases such as taking an already taken field and makes checking for game end criteria very easy.
• fields that have logic whether they are taken or not and by whom
• game with a current state field that was recalculated as the actions were performed on it and methods that could set this externally to make it easy to test

Most of the game classes had very nice explicit methods for checking different game end criteria. During a short retrospective at the end, some participants said that their code was very nicely isolated and encapsulated, with “less leakage than normal”, and that very explicit specifications ended up in the code making it easy to understand.

Multiple models

This exercise reminded me again about Eric Evans’ introductory presentation to domain modeling. One of the basic ideas there is that the best models are not the most realistic ones but the ones that allow us to describe a particular problem efficiently. The best models are good because they serve a particular purpose in a particular context, so a bag of fields might be a better model of the tic-tac-toe game than a 3×3 board even if the latter feels much more realistic and natural.

Conclusions

In my view, this exercise worked really well. It was interesting to observe it from a different perspective (this time I got the role of the annoying git who went around the room and deleted code that people wrote and did not need). Tic-tac-toe was a good choice as it did not require spending time on explaining and comes with an almost guaranteed 3×3 pre-conceived model. Some participants suggested that we should have done requirements 5 and 6 first and then moved to 1-4. Although this would take away the big refactoring moment, it might actually work better to allow people to factor out a very different model straight from the start. Introducing that the exercise is a bit annoying at the start was also a good idea, as I think that it went smoother than the original one with less opposition to dropping unnecessary code.

You can see some of the code examples on the openspacecode repository. For more information on the original exercise and the rules, see my earlier post about it. Mark Needham repeated the exercise earlier as well, building a message interceptor – something much more technical and practical than a tic-tac-toe or Go game. You can read his conclusions at markhneedham.com.