Hi! Hello! Good Day!

Alastair Smith

I'm Alastair, a software developer based in Cambridge, UK. I work primarily in the Microsoft space with C# and the .NET Framework, but fiddle around with many other technologies and languages such as WiX, PowerShell, and PHP.

I'm the founder of the Cambridge Software Craftsmanship Community (CSCC), a group set up to promote and encourage professionalism the software industry. Currently we run two meet-ups per month: a round-table discussion on the first Tuesday, and a hands-on session on the third Tuesday.

I'm also a keen amateur bassoonist, playing regularly with the Cambridge Graduate Orchestra and the Huntingdonshire Philharmonic. In 2009, I achieved the DipABRSM in Performance on the instrument. I 'dep' for various ensembles in the Cambridge area including Cambridge Symphonic Winds, the City of Cambridge Symphony Orchestra, and the Uttlesforde orchestra. Contact me if you would like me to play.

CodeBork.com

CodeBork is my main blog where I write on technical subjects, mostly programming.

Updates to Bob, v0.2 released!

Recently I introduced a new library to aid testing in C#, Bob. I've made a couple of updates to it recently, one small, and one a bit larger. The latest release tackles a few robustness issues and sees it move out of alpha phase and up to version 0.2!

Support for Complex Types

The first new feature is support for complex types with parameterless constructors. You can now say A.BuilderFor<Customer>().WithAddress(new Address()), for example. As it turned out, Bob already supported this as, of course, types with parameterless constructors are easily constructed by the reflection API. There are now tests around this use case, however, so you can be sure it will continue to work!

Support for Named Arguments syntax

The second new feature is a little larger: supporting a different syntax taking advantage of C# 4's support for named arguments. You can now say A.BuilderFor<Customer>().With(customerId: 43), for example, and you can supply multiple properties to the same call, such as

A.BuilderFor<Customer>()
    .With(customerId: 43,
          givenName: "John",
          familyName: "Doe"
    ).Build();

This might be useful if you have a set of properties that always travel together (and so might help you identify where a new class could be introduced).

As before, you can skip the call to Build() if the compiler can work out that you're after an instance of the built type.

Robustness

I've done a bit of redesign which threw up some places where the library wouldn't work quite as intended (e.g., see what happens if you call a builder method that doesn't start with the word 'With'). I now have a design I'm happier with, and have ironed out these peculiarities of functionality, and now feel that it should be more solid than previously. As such, I'm very happy to announce that I've removed the "alpha" tag from the package version and have bumped it to v0.2!

Get Bob v0.2

All of these changes are available from NuGet in the 0.2 version of the package, just install-package BobTheBuilder!

Happy building!

Introducing Bob

TL;DR

Test Data Builders are awesome and you should use them to tidy up your test code (read about them in GOOS Chapter 22). I'm introducing a new library called Bob which replaces the need to write your own hand-rolled Test Data Builders with a generic solution that preserves the fluent syntax suggested by GOOS.

Test Data Builders

One of the most influential books on software development practice in recent years is Growing Object Oriented Software, Guided by Tests, or GOOS for short. It describes an approach to application development based on Test-Driven Development, but demonstrates how to effectively use Mocks, Stubs and Fakes to drive your application's design from the outside and model it around the communications between collaborators, rather than stored state.

A key recommendation GOOS makes for keeping your test code clean is to use a technique called Test Data Builders (Chapter 22, p257). This approach leans on the Builder pattern from the Gang of Four (GoF) to abstract away the construction of objects on which your tests depend, but do not necessarily care about. For example, say you are developing an online shop, which models customers and orders. You might write your tests like this:

[Fact]
public void Placing_An_Order_Adds_The_Order_To_The_Customers_Account()
{
    // Arrange
    var customer = new Customer(1, // Id
                                "Joe", "Bloggs", // Name
                                "10 City Road", "Staines", "Middlesex", "AB1 2CD" // Address
                                );
    var order = new Order(1, customer);

    // Act, Assert: not interesting for this example
}

After a while and a couple of tests, you realise you've got some duplicated code that you could factor out, so you introduce a couple of factory methods. Maybe you even include default parameter values to allow you to reuse the same factory method:

[Fact]
public void Placing_An_Order_Adds_The_Order_To_The_Customers_Account()
{
    // Arrange
    var customer = CreateCustomer();
    var order = new Order(1, customer);

    // ...
}

private Customer CreateCustomer(int id = 1,
                                string givenName = "Joe",
                                string familyName = "Bloggs",
                                string addressLine1 = "10 City Road",
                                string addressLine2 = "Staines",
                                string county = "Middlesex",
                                string postCode = "AB1 2CD") 
{
    return new Customer(id, givenName, familyName, addressLine1, AddressLine2, county, postCode);
}

private Order CreateOrder(Customer customer, int id = 1)
{
    return new Order(id, customer);
}

But time goes on, and you find this approach isn't really working for you either. Perhaps you have somehow ended up with three versions of CreateCustomer() that take different dependencies, or some abstraction is leaking all over your tests in spite of your best efforts. This is where the Test Data Builder pattern comes in.

The Test Data Builder pattern is really just an implementation of the Builder pattern from GoF. This is a creational pattern, like the more common Factory Method and Abstract Factory patterns, and while it is more complicated than either factory pattern, it provides more flexibility too. It achieves this by separating the construction of the object from the object's representation. As defined in GoF, it is a fairly complex pattern, but GOOS simplifies it somewhat.

We start by defining a Builder class for the type we need to construct, which defines a Build() method returning the type we need:

internal class CustomerBuilder
{
    public Customer Build()
    {
        return new Customer(1, // Id
                            "Joe", "Bloggs", // Name
                            "10 City Road", "Staines", "Middlesex", "AB1 2CD" // Address
                                );
    }
}

So far, so uninteresting. Next we start adding methods to define how we want the built Customer to look:

internal class CustomerBuilder
{
    private string givenName;
    private string familyName;

    public CustomerBuilder WithGivenName(string newGivenName)
    {
        givenName = newGivenName;
        return this;
    }

    public CustomerBuilder WithFamilyName(string newFamilyName)
    {
        familyName = newFamilyName;
        return this;
    }

    public Customer Build()
    {
        return new Customer(1, // Id
                            givenName, familyName
                            "10 City Road", "Staines", "Middlesex", "AB1 2CD" // Address
                            );

    }
}

There are two things to notice from the above code sample. First, we get to remove those pesky comments because the code now better reveals its intent: it is self-documenting, which is the dream.

The second thing to notice is the builder methods return the current instance of CustomerBuilder. This allows us to chain calls to the builder methods together to form a nice fluent interface:

[Fact]
public void Placing_An_Order_Adds_The_Order_To_The_Customers_Account()
{
    // Arrange
    var customer = new CustomerBuilder()
                           .WithGivenName("Joe")
                           .WithFamilyName("Bloggs")
                           .Build();
    var order = new Order(1, customer);

    // ...
}

Much nicer! This can be combined with a Factory Method in your test fixture to create the CustomerBuilder, which can make the code fully fluent:

[Fact]
public void Placing_An_Order_Adds_The_Order_To_The_Customers_Account()
{
    // Arrange
    var customer = ACustomer()
                       .WithGivenName("Joe")
                       .WithFamilyName("Bloggs")
                       .Build();
    // ...
}

private CustomerBuilder ACustomer()
{
    return new CustomerBuilder();
}

Furthermore, you can add methods to your Builder along the lines of WithNoFamilyName() to make explicit situations where that part of the object should not be set. For example an Address object will have optional information such as AddressLine2, or you may wish to test what happens when no post code is provided as part of the address.

Mark Seemann proposed a couple of extensions to the original GOOS Test Data Builder, which are quite nice. The first is to use the constructor of the Builder to define any default values that must be provided to the object being built. The second is to define an implicit cast from the Builder to the built type, to eliminate the noise of explicitly calling Build() all over the place:

internal class CustomerBuilder
{
    // ...

    public static implicit operator Customer(CustomerBuilder builder)
    {
        return builder.Build();
    }
}

Introducing Bob

I've been writing Test Data Builders for a good number of months now, and as useful as the pattern is I find myself feeling frustrated at the amount of boilerplate code it demands: the builder methods in particular are quite annoying as they are so similar. I started off by trying to reduce the amount of typing I had to do by using ReSharper templates to stub out the different facets of the pattern such as the builder class, the builder methods, etc., but then I moved jobs and lost them all. I haven't yet got around to reproducing the templates in my new dev environment.

Then a couple of days ago I had an idea. Simple.Data uses the Dynamic Language Runtime and the dynamic dispatch features of C# to offer methods that represent columns in your database tables (e.g. pets.FindById(256);, pets.FindByType("Dog");, etc.). Perhaps the Test Data Builder pattern implementation can be generalised using the techniques?

I spent today spiking a new library to do this, Bob. You use it like this:

[Fact]
public void Placing_An_Order_Adds_The_Order_To_The_Customers_Account()
{
    // Arrange
    var customer = A.BuilderFor<Customer>()
                       .WithGivenName("Joe")
                       .WithFamilyName("Bloggs")
                       .Build();
    // ...
}

It also implements Mark's second extension to the pattern, whereby you can implicitly cast from the Builder returned by BuilderFor<T>() to T and have it invoke the Build() method to complete the conversion.

It is, admittedly pretty limited in functionality at the moment because it's a proof of concept. It will only build instances of types that have a default (i.e. parameterless) constructor and that provide public setters on properties for the things that are to be set. I will build out the functionality as I need it, and I have published a Task list of immediately-forthcoming functionality.

Check it out and let me know what you think!

Software Craftsmanship, and Professionalism in Software

Another thing to come out of my reflections on Software Craftsmanship at SoCraTes UK this weekend was a clearer view on what professionalism means to me for software craftsmen. I believe there are three pillars of professionalism that need to be considered:

  • A mindset of taking a methodical, deliberate, and considered approach to your work;
  • Leaning on your tools, but not being dependent upon them; and
  • Taking personal responsibility for your decisions and actions

The First Pillar: Mindset

The first pillar, that of the approach one takes to their work, is what allows us to deliver quality software. It is also, perhaps, one of the things we would like to be judged on when sharing our work with others. It is about being careful (not, in this context, in the "cautious" sense of the word) in our implementations to ensure that what we deliver meets our standards. Let's delve into each of the words I used a bit further.

Methodical

A methodical approach is one that is systematic and orderly. For example, the Test-Driven Development process takes the form of three steps that are repeated in a loop: red, green, refactor; red, green, refactor; red, green, refactor; etc. This process is both systematic - it encompasses a system that is defined as "implement software incrementally, by writing your tests first, making the tests pass, and making incremental improvements to the tests and implementation" - and ordered, in that the steps have to be completed in the order listed: you can't refactor code when you have failing tests, and if you end up with failing tests after making another test pass (or during a refactoring), you have broken something.

It goes further than this, however: for example, seeing the test fail for the right reason. That is, if your test passes because your code already covers the case you're now testing, you go back and change your implementation code to make that new test fail. If you see the test fail because of a compilation error, or because of an exception thrown, you go back and make sure the assertion itself fails when the behaviour it is testing fails.

Deliberate

A deliberate approach is one where each of the steps are there for a reason, they have a specific intent. Taking again the Test-Driven Development process of red-green-refactor as our example, we can see that each of the steps in the process have a purpose, and in the order described. By writing our test first, we commit to a small unit of behaviour that we specify with the test. In the green phase, we implement the behaviour specified. Finally, in the refactor stage, we incrementally improve the design of our code to remove duplication and other smells.

Again, this also ties back to seeing the test fail for the right reason. Each of the three steps are there for a purpose, so we don't skip over any of them even when it looks like we've met the high-level goal of making bar go green or red; we dig into it further to ensure that we've achieved that goal for the right reason, that the purpose of the current step has been satisfied.

Considered

A considered approach is one that you have thought about, one that you can defend for your own reasons when challenged on it. You have made the decisions you have, and taken the approach that you have, as the result of thinking about what it is you are doing; not simply following orders, or naively following a process, or being a passive participant in your team's activities.

When I first picked up TDD, I did so without contemplating in much detail the approach it defines. As a result, when I came to introduce the concept to my team at work, I had some tough questions to answer from them about the value of the approach and the detail of the process that I wasn't able to satisfactorily address in some cases.

The Mindset: Mindfulness

Mindfulness is perhaps most easily understood as the very opposite of mindlessness, a word many more people are familiar with: we can all picture a person working as an automaton, completing a task they've done hundreds or thousands of times before, doing it without thinking, without engaging with the task at all. We've all had the experience of making a journey somewhere, perhaps on foot, by bike, or in a car, and arriving at our destination without much recollection of the journey there. Mindfulness is about engaging with the task you're undertaking, being an active participant.

Taking a methodical, deliberate and considered approach to your work instills a mindset of mindfulness in your work, which I believe is important to mastering your craft. Being mindful of your work provides you with greater opportunities for learning from your mistakes, the situations you encounter at work, and the context around you. It means challenging your practices and principles, and accepting that they will be challenged by others. It means thinking about what you are doing and justifying your approach to yourself.

You might be reading this and thinking that what I'm suggesting sounds like perpetual self-doubt; this is not the case. Self-doubt comes at this process from a negative position, where you're questioning your motives and decisions for the simple reason that you made them. Mindfulness comes from a much more positive position, that of curiosity: you question your approach with the intention of learning from the decision, you're curious as to whether there is a better approach that can be taken, a more efficient practice that can be learned, etc.

The Second Pillar: Tools

Every craftsman has his or her tools: the carpenter has saws, hammers, lathes and more; the surgeon has a scalpel, an endoscope, and sutures; the software developer has their editor or IDE, refactoring tools, test runners, version control system, and more. Tools are an important part of any craftsman's job, and knowing your tools well can be the difference between doing a good job and bad job, producing quality product over poor product, creating more product over less product, etc.

A craftsman should not be dependent upon their tools, however. Being prepared to put a tool to one side to try a new one out is just part of this: how will you know if something better is available if you never try it? For example, a large number of C# developers have a copy of ReSharper at work, and many have their own copy at home as well. This tool came about in the first place because of poor support within Visual Studio for basic refactoring operations like rename and extract method. However, there is a manual approach, described by Martin Fowler in his original text on refactoring: add-update-remove. It is a methodical, deliberate, and considered process that allows you to complete a refactoring manually without seeing a compilation error; for example, if adding a parameter to a method:

  1. Add a new overload of the method that includes the new parameter, and make it call the existing overload.
  2. Update all usages of the existing overload of the method to point to the new one, supplying the new argument as appropriate to that context.
  3. Remove the old overload that is now unused everywhere, migrating the implementation to the new overload in the process.
  4. Make the changes needed to the implementation to use the new parameter.

If you're using a modern version control system like Git, then you can commit after each of these stages as well, so you get a set of handy staging posts you can roll back to if necessary.

Here are some of the tools I consider essential for any software craftsman, no matter what language they are working in:

  • The best-available editor for your language (defined on your own terms). Perhaps it's Visual Studio for C# developers, IntelliJ IDEA for Java Developers, vim/emacs for Ruby/Python/JavaScript developers; perhaps you prefer SharpDevelop, Eclipse, or PyCharm.
  • A plain-text editor. Often we need to make a small change to a file, or write a commit message, or edit a supporting file. Firing up a complete IDE is overkill for this kind of scenario, so it is worth keeping around a plain-text editor for these situations, and one a little less basic than Notepad at that. I've tried a few over the last 10 or so years, and have recently come to settle on Sublime Text 2, and vim.
  • A scripting environment. Linux users have had Bash and other shells available since the beginning of time (1 Jan 1970, as we all know). Windows now has PowerShell, and if you're a developer working in Windows regularly, you owe it to yourself to learn PowerShell well. Scripting environments put the power of automation at your finger-tips, which can be a huge time-saver.
  • An automated refactoring tool (if available). Some IDEs have these built in, particularly JetBrains' offerings. Visual Studio has a number of "productivity extensions" including ReSharper, CodeRush and JustCode that bring the full weight of this functionality to bear over VS' limited offering.
  • A Distributed Version Control System, such as Git or Mercurial. Having the ability to commit and roll-back changes locally before going anywhere near a central repository is an incredible advantage: with a bit of discipline in committing, you can mess up your working copy as much as you like and always have a recent checkpoint to revert to. Git is my weapon of choice in this arena.
  • An automated test runner, ideally with a continuous mode. I started using NCrunch, a continuous test runner for Visual Studio, about 18 months ago. On projects with proper unit tests, it provides a fantastic productivity boost just having the tests running all the time in the background on each change. JavaScript developers have karma (amongst other options, I'm sure), and there are similar things available for other languages too. At work, I use ReSharper's test runner because it integrates very nicely with my IDE and our tests at work don't play nicely with NCrunch.

Each of these tools are integral to my development process, and serve a very specific function, in exactly the same way that a lathe, a saw and sandpaper are to a carpenter's wood-working process.

The Third Pillar: Personal Responsibility

Erik Talboom's Lightning Talk on Personal Responsibility at SoCraTes UK evidently struck a chord with everyone in the room: it was a recurring theme in sessions and conversations throughout the weekend.

Erik explained well Christopher Avery's Responsibility Process in terms of finding and fixing a bug:

  • Denial. First you cannot believe there is a bug. "There's no way that could happen!", you tell yourself.
  • Blame. Next you start looking around for someone to blame for the bug. "This is Joey's code, it's his fault!", you tell yourself.
  • Justification. Third, you look for excuses for the bug being there. "Well, if Joey hadn't used null values in his code, there would be no bug!", you tell yourself.
  • Shame. Next, you start to lay blame yourself. "I'm such an idiot. I saw Joey working on this just last week and I didn't say anything.", you tell yourself.
  • Obligation. Now the context and environment are at fault. "There's no way we could have done anything different, we're under such pressure to deliver on time that quality goes out the window.", you tell yourself.
  • Responsibility. You realise there's something you can do about it. "I'll have a chat with Joey to explain why nulls should be avoided, and start trialling code reviews as part of our development process."

The alternative to responsibility, of course, is abdicating it: quitting the situation to avoid the pain associated with shame and obligation.

A key part of taking personal responsibility is mindfulness: being aware of when you are in the mental states of denial, blame, justification, etc. This awareness can help you move through the remaining stages more quickly (or skip them entirely) to reach a productive conclusion earlier.

Conclusion

Mindfulness and Personal Responsibility are the two key "psychological" components of professionalism to me; the second pillar, Tools, provides a way of expressing those through our practices. Any amateur can use a professional's tools, but it is the approach we take to our work that indicates professionalism and denotes craftsmanship.

A Plurality of Ideas: Contrasting Perspectives of Software Craftsmanship

Attending SoCraTes UK over the weekend got me thinking about Software Craftsmanship in general, and the different perspectives within the movement was one of those things, particularly the differences, as I perceive them, between the North American* and the European schools.

Software Craftsmanship started off in the US about 5-6 years ago, as something of a reaction against the sea change in the agile movement away from technical practices. I first came across it myself in 2010, and it looked right up my street, so I promptly booked myself onto that year's Software Craftsmanship UK conference at Bletchley Park. I liked the technical focus of the conference, particularly the hands-on nature of it, and I've been every year since (hopefully see you there in October!). Reading more about the movement, I saw a great deal of focus on practices, particularly those inherited from XP like pair programming and Test-Driven Development.

A couple of years later, I started attending the London Software Craftsmanship Community meet-ups. Initially, I went along to their workshops to learn something new about the act of developing software, a new technique to try out, practice my TDD, etc. A few months later, I started attending their Round Table discussions as well, and found the opportunity to talk to other craftsmen invaluable. Discussions around Domain-Driven Design, corporate cultures, motivation, and hiring good developers, were just some of the highlights of the conversations there.

Clearly on display at SoCraTes UK this weekend was a plurality of ideas, and people willing to reflect on their craft and develop their understanding through the challenging of their principles, practices, ideas, and beliefs. I saw this across the group of 70 people attending from at least 5 countries in Europe. It could easily have been an exercise in navel-gazing, but what we had instead were productive discussions that helped us form a clearer collective picture of the concept of Software Craftsmanship.

Something we discussed in the fish bowl at the start of the conference was whether Software Craftsmanship was becoming a religion, particularly in the way we share our values with other people. @sleepyfox made the point that we shouldn't be trying to bring our values to other people, because it's too much like a religious war, or a crusade. That way lies dogmatism, the antithesis of what lies at the heart of Software Craftsmanship. I fear there are some elements of Software Craftsmanship that are becoming religious and dogmatic, and that as a result the movement as a whole is starting to lose some of its pragmatism.

What I have thought for a long time now is that Software Craftsmanship is really about more than just the technical practices. The manifesto talks about "a community of professionals" and "productive partnerships", for example, as well as "well-crafted software". The further reading page on the Software Craftsmanship website includes links to blog posts, including one asking "Is Craftsmanship all about code?"

Unfortunately, it seems to me that the North American school of Software Craftsmanship is all about code. Corey Haines brought the world the Code Retreat, and JB Rainsberger the Legacy Code Retreat. Uncle Bob travels the world talking about Clean Code, TDD, the SOLID principles, and more. I'm enormously grateful to these people for providing such important and valuable formats for learning, and for sharing their knowledge with the world to better the technical state of the industry. When I look at the North American Software Craftsmanship movement, however, it feels to me like there's something missing.

Practices come and go, and those that tie themselves to their practices risk irrelevance. I firmly believe that Craftsmanship practices (or XP practices), such as pair programming and Test-Driven Development, have inherent value to the extent that everyone should learn them. Learning them is different from using them all the time, however: there situations where TDD is a difficult practice to apply, such as when working with a large body of legacy code. While you can use TDD in some cases in this context (e.g. when adding new classes and functionality), in the main you have to adopt a test-last approach for the simple reason that the code has already been written, the design has already been decided. Other techniques, such as the Golden Master and incremental refactoring, will keep you more productive than TDD in this context.

The North American school's focus on technical practices opens us up to criticism along the lines that we have seen: "you're TDD Nazis", "you're too focussed on code", and "you're elitist". This last one stings the most for me: yes, we are actively trying to improve our craft, and yes we want to improve the industry, but we want to do that in as an inclusive way as possible. It's not a case of converting people to the Software Craftsmanship religion, it's a case of inspiring people of all abilities to seek to better themselves through our ethos of mentoring and peer learning.

What I see in the European school of Software Craftsmanship is a superset of the North American school: not just technical practices, but discussion, collaboration, learning and mentoring. It feels more fully-formed to me as a result, more holistic, more inclusive and welcoming. Perhaps it's a difference between European and North American cultures being expressed in the equivalent parts of our community, or maybe it's that the European school is an evolution of the North American school; I don't know. What I do know is that, while I see value in the technical focus of the North American school, the European school is the idea of Software Craftsmanship I identify with the most, and the one I will continue to promote.


* It might be unfair to generalise the North American movement as such. It's entirely possible it would be more accurate for my comments on the "North American school" to instead be addressed to the "Chicago school". I would be interested in hearing from someone with more knowledge of the movement that side of the Atlantic. Return to article

SoCraTes UK 2013

This last weekend I attended the SoCraTes UK conference at the Farncombe Estate in the Cotswolds, near Moreton-in-Marsh. It was a fantastic weekend of mixing with, talking to, and learning from other software craftsman from around the country and across Europe.

Organised by Sandro Mancuso, Samir Talwar, Gonçalo Silva and Mashooq Badar (apologies if I missed anyone), SoCraTes took the form of an open space or "unconference" with no formal structure or agenda. Such a format requires good facilitation, and we had one of the best in the business: Rachel Davies of Unruly Media, and co-author of the first book on Agile Coaching.

SoCraTes started on Thursday evening with a series of lightning talks from attendees, followed by a fishbowl-format discussion session after dinner. The highlights of the lightning talks for me were @sleepyfox's talk on Why Gödel's Incompleteness Theorem Renders Estimation Meaningless (apparently delivered completely off the cuff!), whether personal responsibility should be common knowledge for all software craftsman (delivered by Erik Talboom), and Chris Whitworth's talk titled Naming things is hard but that's no excuse. I'm also looking forward to trying out on a couple of codebases Dmitry Kandalov's tool for code history mining.

The fishbowl discussion was a new discussion format to me, but it turned out to be quite similar to the park bench-format discussions sometimes held at Skills Matter. It started off with a panel of four people, who were tasked with discussing, and attempting to answer, three questions about software craftsmanship. Any time someone from the audience wanted to contribute they had to take the spare seat on the panel, and someone on the panel had to vacate their seat. As the discussion began to up, I started to see how the format got its name: the people in the room were moving around the room like fish in a bowl. I thought the format worked well, although it was unfortunate that only a fraction of people in the room contributed their thoughts.

The open space itself ran over Friday and Saturday. Talking with Rachel at the end of the event on Sunday, it was interesting to learn about the origins of the format. The person who came up with it was running a lot of events and found them a lot of work to put together, particularly around the selection of sessions; additionally the feedback that he got strongly suggested that the coffee breaks between sessions were the bits the attendees found most valuable. As as a result, he devised a format that removed the work of putting together a schedule and put the focus on collaboration, conversation and communication with other attendees.

We began the open space on each day with a plenary-type session where people interested in proposing sessions wrote their idea down on a big (A5-sized!) sticky note. We had 9 rooms available over 6 time slots (three before lunch, three after lunch), so everyone who proposed a session got a chance to deliver it to at least a handful of people. The great thing about the open space format is the set of guidelines (and one law) that define it:

  • The Law of Two Feet: if the session isn't turning out the way you'd expected and there is something else you'd like to try, just move on to it. Your two feet are your foot of passion and your foot of responsibility, so stand up for your passion as well.
  • Whoever comes are the right people
  • Whatever happens is the only thing that could have
  • Wherever it happens is the right place
  • Whenever it starts is the right time
  • When it's over, it's over

Earlier sessions spawned new sessions later on, some sessions spilled over into one or more later slots and moved to a new space, and everyone had invigorating discussions.

I attended three sessions on the first day: refactoring the 13 rules of TDD into a more manageable list, WTF Code (with some great examples of how not to use ints and Integers in Java!) and Dealing with Legacy People. This last was a fun discussion, if perhaps not hugely productive, of ways of dealing with people in positions of authority (e.g. team lead, architect) that haven't kept their skills and knowledge up-to-date and aren't willing to accept constructive criticism of their work. I took a break before that session to do a spot of hands-on coding: there's something about being amongst that kind of people that brings out my passion for coding.

I had fuller day on the second day. I spent the first two sessions in Marcin Gryszko's DDD Practice session, then went to a Cyber-Dojo before lunch. I took the first session after lunch off, and then joined Erik and Ian Russell's discussion session on Personal Responsibility, which overran into the final slot of the day.

Marcin's DDD session I found invaluable; it was like the Architectural Katas devised by Ted Neward, but for Domain-Driven Design. I learned from Sandro that the key thing is to start with your application's services (which, in the exercise in this session, were loosely tied to use cases) and identify the entities and values from there; previously I'd been working the other way around. This makes a lot more sense to me now, particularly after someone else described it as working outside-in.

The final day of SoCraTes UK was a lovely walk around the Cotswolds, led by Rachel. It was exactly what I needed in my slightly-hungover-from-Saturday-night state!

SoCraTes UK was also my first experience of speaking at a conference, and in many respects I think I chose a good event for my first time: the audience were friendly and supportive, and interested and engaged, not least because everyone was there for the simple fact that they wanted to be! The format of my session (a prepared talk with slides and everything) didn't really fit the format of the conference, though, so I will remember to keep that in mind when preparing sessions in future. I will blog about my session separately to keep this post down to a vaguely manageable length.

The most interesting thing for me over the course of the conference was the shared vocabulary that emerged during the weekend: "personal responsibility" and "mindfulness" being two repeating themes. The most valuable thing for me was the opportunity to reflect on our principles, values and practices with like-minded people, who invited open discussion and debate on those very things: "strong opinions, weakly held" was the line from Samir that summed it up best for me.

The most unexpected thing for me was the opportunity to chat with leaders in the Software Craftsmanship movement across Europe as equals. Occasionally it has been the case at other conferences and events (particularly the more formal and structured ones) that the speakers are set apart from the attendees, which can make it more difficult to interact with them. At SoCraTes, it was the complete opposite: it was just a bunch of people in a room.

A little surprising for me was the interest other people had in the Cambridge Software Craftsmanship Community and how it was progressing. I must have had conversations along these lines nearly 10 times over the course of the weekend, which was ace. Having stepped back from the London Software Craftsmanship Community in the last year or so, not least to focus on getting CSCC up and running, I now realise that we'd become a little bit isolated up here in Cambridge from the rest of the Software Craftsmanship community. I intend to fix that by starting to attend the LSCC meet-ups again from next month, and encouraging more inter-community collaboration, through things like Craftsman Swaps, workshops and joint code retreats; other ideas welcome, of course! I'm hugely looking forward to seeing more CSCC attendees at SoCraTes UK 2014.

I'd like to say a note of thanks to everyone that helped out with the organisation of SoCraTes UK, to everyone that delivered sessions, to Rachel for her top-notch facilitation of the event, and to the following people for the varied, wide-ranging, detailed, and down right funny discussions I had with you over the course of the weekend: Ian Russell, Teo Danciu, Nicole, Andreas, James Lewis, Raphael Ackermann, Dmitry Kandalov Erik, Sandro, Mani, Rachel, Emanuele Blanco, @sleepyfox, and Chris Whitworth. It was a pleasure meeting or catching up with you all, and I'm looking forward to seeing you again soon!

ReelCritic.co.uk

ReelCritic is a newer blog that I set up to discuss film and television news and events. I mostly use it to post reviews of films that I have seen.

The Doctor's Regeneration

The eleventh doctor bursts on to our screens with a rejuvenated energy in a fun and fast-paced new adventure.

read more

Green Zone

StarStarStarStarEmpty Star

A tightly-wound plot offers high-octane thrills and spills, but the climax is more than a little overblown.

read more

Alice in Wonderland

StarStarStarEmpty StarEmpty Star

This mostly enjoyable romp, with an interesting mixture of performances, falls on its flaws.

read more

'Avatar' and the Awards

Some thoughts on Avatar's performance the awards' ceremonies, most notably the Oscars.

read more

Avatar

StarStarStarStarStar

A somewhat predictable plot does nothing to spoil the immersive and enthralling trip to Pandora.

read more

GitHub

I use GitHub extensively to manage my personal projects. Here's a list of my public-accessible repositories; if you are a collaborator on one of my private repositories and are logged in to GitHub, you'll be able to see those too.

Photography

I'm an amateur photographer. I like working with natural light, particularly outdooor and landscape scenes. I shoot with a Nikon D90 digital SLR camera and either a fast 50mm prime lens or a slower 18-105mm zoom lens.

My photographs are hosted on Google's Picasa service.