Mark Needham

Thoughts on Software Development

Alt.NET UK Conference 2.0

with 10 comments

I spent most of yesterday at the 2nd Alt.NET UK conference at Conway Hall in London.

First of all kudos to Ian Cooper, Alan Dean and Ben Hall for arranging it. There seemed to be a lot more people around than for the one in February which no doubt took a lot of arranging.

It was again run using the open spaces format and we started with an interesting discussion on what Alt.NET actually is. There’s been quite a bit of discussion in the blogosphere and everyone seemed to have a slightly different opinion – for me it’s a group of people who are interested in improving how they work in .NET. Ian Cooper pointed out the Foundations of Programming e-book as something concrete which has been released regarding what Alt.NET actually is.

The day was again split into four streams – I stuck to the more general software development oriented discussions.

Agile

This session focused on agile estimation session techniques. Mike Cohn’s book is probably the best known reading in this area.

Ian Cooper raised an interesting idea around the discussion of estimates – he suggested getting the person with the highest and lowest estimates to explain why they had given that estimate to help bring out the different assumptions that people were making regarding the story.

He also spoke about his use of Alistair Cockburn’s Crystal methodology which advocates a 3 phase approach to development whereby you start with the skeleton of the system early on and gradually fill it out in future iterations. I have read a little bit of the book but never used it myself so it was interesting to hear a practical experience.

The idea of only releasing software when it is actually needed rather than at frequent 2 week intervals regardless was also raised but from what I’ve seen on my projects when there are releases it is because the software is needed by the users. I think this is more a case of pragmatically using the methodology rather than sticking to precise rules.

Acceptance Testing

A lot of the focus in this session was around how we can improve the communication between BAs, QAs and Developers when it comes to writing acceptance criteria.

Gojko Adzic suggested the idea of having an Acceptance Testing 3-Some before a story is played so that these tests can be written with all opinions taken into account. The idea here was that the tests written would be more accurate and hopefully reduce the problem of having to go back and change them later on.

While this idea seems good I am more of the opinion that we should just go with the acceptance tests that the QA writes, implement those, then check with the business whether everything is covered. The feedback loop in this approach is much shorter and as the key to software development for me is getting frequent feedback I prefer this approach. This is certainly the way we have done things on the ThoughtWorks projects I’ve been a part of. Requirements by Collaboration was pointed out as being a good book to read with regards to getting everyone involved in the process.

The idea of having a ubiquitous language that everyone in the team used to describe acceptance tests was another good idea that came out of discussions – although I think if a team is developing software using a Domain Driven approach then this is likely to happen anyway.

A large part of the session focused on UI tests and the problems people experienced with regards to brittleness and long running time. One way to get around this is clearly not to have so many tests at this level – one idea was to only have automated UI level tests for critical scenarios e.g. logging into the system and then manual test other scenarios.

One way we have got around this on the projects I’ve worked on is by having a level of tests one level down which test component interaction separate from the UI – typically called functional tests. These could be used to test things such as NHibernate logic rather than doing this through the UI. We would also look to keep minimal logic in the presentation layer as this is the most difficult part of systems to get automated tests around.

TextTest was mentioned as being an acceptance testing tool which tested the system by going through the log files. This has the added benefit of forcing you to write more useful logging code. Green Pepper was also mentioned as a useful way of using acceptance tests which link together Jira and Confluence.

Domain Driven Design

The discussion (perhaps not surprisingly) focused on the concepts described in Eric Evans’ book.

The value of having rich domain objects with the business logic inside was questioned with Ian Cooper pointing out that business logic need not necessarily be business rules but could also describe the way that we traverse the object graph. In particular the Law of Demeter was discussed as a way of avoiding an anaemic domain model.

The problem of designing from the database upwards resulting in these anaemic objects was raised – one potential solution being driving the design from acceptance tests i.e. top down.

Ian Cooper pointed out that coding in a Domain Driven way with lots of plain C# objects made testing much easier. I think in general keeping the behaviour and data together in an object makes it easy to test. Doing this using a Domain Driven approach just makes it even easier to use the code as a communication mechanism.

There was also discussion around the use of Data Transfer Objects, with the general consensus being that using DTOs was good around the UI to save you having to deal with incomplete domain objects around these areas.

The idea of the UI being outside the bounded context that our domain model is used in was also suggested which strikes me as a good idea – would be good to see it done in practice though.

It was suggested that DDD is only useful in complex domains. I think this is true to an extent but some some of the ideas of DDD are just good software development principles such as having a common/ubiquitous language in the team. Ideas such as bounded context are clearly only necessary when there is a greater level of complexity.

I would certainly recommend picking up a copy of the book – 90% of what was discussed is in there.

Developer Education

This was the most interactive session I attended and the majority of the people in the room were able to offer their opinions which I thought was much more aligned with the spirit of the open spaces format.

The discussion focused on how the environment that you’re working in influences your enthusiasm for learning new technologies and new ways of doing things. I am lucky in that working for ThoughtWorks I have colleagues who are very enthusiastic about technology and encouraging other people to learn.

The Ruby community was pointed out as one where there appears to be much more enthusiasm than there is in the .NET world. I’m not sure how exactly we can measure this but blogging wise the Ruby guys definitely have the edge. I think some of this can be explained that people who ran with Ruby early on are massive technology enthusiasts and you’re unlikely to start working with Ruby because you have to – it normally starts out for the love of the language from my experience.

A suggestion was made that holding Brown Bag sessions at lunch time where people could share their learnings with colleagues was a good way of helping to share knowledge. This is certainly an idea that we use frequently at ThoughtWorks and there is actually even more value in the conversations which come afterwards.

The Google idea of 20 % time to dedicate to your own learning was raised as being ideal, although it was pointed out that this was a hard thing to implement as getting things done always takes precedence.

Overall

It was an interesting day and it’s always good to hear the experiences of other people outside of ThoughtWorks.

I think we need to try and find a way that more people can get involved because most of the sessions I attended were very dominated by a few people who had great knowledge on the subject. While it is no doubt very useful to hear their opinions I think it would be even better if more people could get to speak.

Be Sociable, Share!

Written by Mark Needham

September 14th, 2008 at 4:28 pm

Posted in .NET

Tagged with , ,

  • Hi Mark,

    First of all, thanks for the write-up, your notes will come in very handy. Again, the key thing for me is that nothing is really carved in stone so if the things that I spoke about don’t work for you, by all means modify them and use something that works.

    I got a sense that we misunderstood eachother while discussing acceptance test workshops. I’m just wondering about this conclusion:

    “While this idea seems good I am more of the opinion that we should just go with the acceptance tests that the QA writes, implement those, then check with the business whether everything is covered. The feedback loop in this approach is much shorter and as the key to software development for me is getting frequent feedback I prefer this approach.”

    Can you elaborate on that a bit more? Why do you think that the feedback loop is much shorter in this case? We all agree that a quick feedback loop is the way to go but I see it exactly opposite: if developers, business and testers do a 4hr intensive workshop on examples/tests, the feedback loop is much shorter then if you get qa to write tests, developers to implement it and then business to review it on the end of the iteration.

  • Maybe I didn’t word that so well! I was more thinking of some of the discussion around having longer iterations (3/4 weeks long) where we need to get this information defined early on (using the Acceptance Testing 3 some) because we won’t see the implementation until a few weeks later on.

    I think there is value in this but I favour the approach of getting an actual implementation of something in front of the business as quickly as possible (maybe even before the end of an iteration) and then refining our understanding based on this. This gives the business the chance to actually see something concrete and then maybe adjust their ideas of what they actually want based on this.

    Maybe we can achieve this short feedback loop by incorporating both these approaches, or perhaps I’m misunderstanding the way that the Acceptance Testing 3-some would be used?

  • Seems like this is causing a lot of confusion, I had the same questions while I was doing the talk at GS this week. I’ll try to put together a blog post on iterations and acceptance workshops to make it clearer. My idea is to organise workshops for small chunks of development. If your iterations are 3-4 weeks long, you can possibly organise two workshops for each iteration, focusing on two weeks of development each. The biggest values of workshops for me are building a shared understanding and flushing out inconsistencies and functional gaps before development starts, not during development. For that, developers have to be at the workshop as well.

    In any case, this is not prescribing the way that people implement software — you can (and should) still keep implementing the software using the best practices that you are using at the moment. AAT is more about ensuring that we all agree on what we need to implement and ensure that we all understand it the same way.

    I’m doing a talk on this on thursday in London (http://skillsmatter.com/podcast/home/agile-acceptance-testing), maybe come and let’s continue the chat after the talk in the pub?

  • Good summary, I’ve got a few questions/comments…

    “The idea of having a ubiquitous language that everyone in the team used to describe acceptance tests was another good idea that came out of discussions – although I think if a team is developing software using a Domain Driven approach then this is likely to happen anyway.”

    Thats an interesting point, my experience with user stories in general was that they don’t follow the UL to a large extent mainly because they often come from the user not the domain expert:

    http://codebetter.com/blogs/gregyoung/archive/2007/10/16/bdd-and-the-shared-language.aspx

    Depends though, if the domain expert is involved in the story (or acceptance criteria) development then maybe you get a lot more shared language.

    “The idea of the UI being outside the bounded context that our domain model is used in was also suggested which strikes me as a good idea – would be good to see it done in practice though.”

    Not 100% sure what you mean here, bounded contexts really relate to the model itself so I’m guessing you mean in terms of having an anti-corruption layer (presentation model) between the domain and GUI?

    “There was also discussion around the use of Data Transfer Objects, with the general consensus being that using DTOs was good around the UI to save you having to deal with incomplete domain objects around these areas.”

    Thats definitely part of it but I’d say the ability to change the domain without having a big ripple affect through the GUI(s) is equally important. Not least as you don’t want to have to spend days/weeks changing the associated GUI(s), changing a little bit of mapping logic is much easier.

    In addition its a pity that we go to all this effort to shield the domain from the database but in practice the GUI can cause as much if not more polution in a complex domain model.

  • Pingback: Should we always use Domain Driven Design? at Mark Needham()

  • Pingback: Similarities between Domain Driven Design & Object Oriented Programming at Mark Needham()

  • Pingback: Alt.NET Sydney User Group Meeting #1 at Mark Needham()

  • Pingback: It’s not all about the acceptance tests at Mark Needham()

  • Pingback: Crystal Clear: Book Review at Mark Needham()

  • Pingback: Environment matters a lot at Mark Needham()