On Tuesday I went to my first software craftsmanship roundtable. This is a monthly event held by the London Software Craftsmanship Community. I had been lurking on their meetup group for a while and online the guys seemed like a really friendly, enthusiastic and knowledgeable bunch.
This is also very much the impression I came away with on Tuesday: A really nice group of guys, who are really into their craftsmanship, leading to lots of interesting discussions.
Those discussions were really helped by the roundtable format and I found this format itself quite interesting:
The evening is split into two with the first part (20 minutes or so) dedicated to Lightning talks and the second part revolving around a group discussion.
Lightning talks are short five minute presentations: If you want to present on a topic, then you bring your topic on the night and you talk about it for five minutes. With this set up, you get a wide variety of topics covered (or at least primed in people’s minds) in a very short time.
For the discussion part, people suggest topics on the night. These get voted on and the group then splits to discuss the two topics with the most votes.
So what did we actually talk about on Tuesday?
The lightning talks covered a wide variety of topics:
This talk was about the first conference organised by the LSCC. The way the conference was organised sounded quite interesting: It was a three day “retreat” in the Cotswolds meaning that you get to talk about software and do some coding in the evenings and after the formal presentations are done. Those formal presentations themselves are all participant volunteered / organised. Effectively, there are some rooms in the venue and you “book” a room and put it on the schedule, if you want to do a talk. I can see how this leads to a great variety of talks. Sounds really cool. None of the conferences I have been to have been residential so I think this would add a very interesting twist too!
This was a short presentation evangelising Apache camel which is an open source message bus written in Java. It is based on the patterns described in the Enterprise Integration Patterns book (something for the reading list). The main point here was that – like a general message bus – it easily enables separation of concerns between business logic, database and UI logic. It also helps with the organisation and communication of separate components.
How long will a program be?
This was a presentation by Derek, the writer of the Shape of Code blog: Derek is writing a book which brings data analysis to programming and publishes parts of it to his blog. His topic for the night was in how many different ways a simple programming problem can be solved. He walked us through the data analysis in this blog post. Really cool stuff and a huge variety of solutions. Some of the shortcomings around his current analysis are that it includes solutions which don’t work and that differences in statement orderings are counted as separate solutions. However, one of the great things is that he publishes his data so you can do your own analysis.
Domain driven design
A short presentation reminding us of the benefits of domain driven design and separation of concern. It definitely moved Eric Evans’ classic further up my reading list.
The two roundtable talks were
- Separation of concern and examples of how people implement separation of concern
- Legacy software: Why do we write code which we know will be legacy code?
I took part in I listened to the legacy software round table.
Some of the key points in that round table centred around:
Technical debt metaphor
This is the often used metaphor in software development for code which is “crappy code” or a “hack”. The idea here is that crappy code forces you like debt to pay interest payments (in terms of time spent on bugs and productivity). The implication being that interest payment may eventually consume the majority of your time. You can find lots of examples of people talking about technical debt in these terms (e.g. here and here).
One of the key points that came out of the discussion is that it is very hard to measure the impact of technical debt. This is partly because it is hard to measure productivity in the first place.
Communication & management buy in
Without measuring the impact of technical debt, it is, however, quite hard to get management buy in to spend the additional effort to “do things properly”. People talked about various techniques for this. These range from abstracting the problem away for management (“it will just simply take this long to do”) to explaining the issues in detail. Approaches vary depending on the individual circumstances (position, level of trust, management technical competence etc.)
Depreciation is the idea that an application’s code goes through a natural cycle of becoming less fit for purpose as other things change (technology, business understanding/requirements). We only spent a little time on this notion, but to me this is one of the more interesting aspects of technical debt.
In some sense, this is fairly close to the “received blogosphere wisdom” on technical debt. However, the discussion has definitely made me reflect on my experience with technical debt and I will probably spend a blog post this week trying to clarify my thoughts.
Another cool aspect of the evening was to learn how diverse programming environments really are. My experience so far has been on the enterprise development side.
This is very different to some of the distributed consumer computing environments that I heard about here. The challenges here are in a sense very similar to the enterprise environment (ranging from separation of concerns, volume requirements to versioning), but they take wildly different concrete forms. This means the concrete implementations of solutions are also very different and so quite exciting.
In summary: lots of really interesting ideas out there and lots to learn!