London Software Craftsmanship Community: Roundtable – 19/02/2014

Admittedly, I only stayed for about half of this Meetup. I left before the discussion started. (This is because the pizza delivery was a little late and we didn’t start until the pizza had been delivered). However, I did manage to catch the lightning talks and, as always, these were excellent.

The topics of the lightning talks this time were:

Code retreat day at work

I think I have described the mechanics of a code retreat day before. This was a little bit of feedback by some of the guys who tried a code retreat at work. They reported that the team they tried this with was reluctant to delete code and not as able to experiment with different solutions: It sounded as if the team was not too sure whether they were being graded on how they performed. I can imagine that it’s very hard in a company, which does not do this kind of thing very often to just see something like the code retreat as just a fun exercise! It’s also very hard work to establish in which everyone is just willing to experiment and be creative!

Advice for the aspiring devop

This talk very strongly echoed an excellent IASA talk I went to the other day, but did not get round to writing about. (You can find the slides here.) It talked about the importance of keeping production in mind. In particular, it talked about how you favour cleaner, simpler and more robust solutions (as well as the importance of logging and diagnostics) if you keep production in mind. One of the books that was mentioned – “release it!” – was also mentioned in the IASA talk so I really need to check this out.

A quick introduction to auto fixture

This was a really short introduction to a unit testing library called “auto fixture”. The main concept behind auto fixture is to reduce the amount of setup code that is needed by creating anonymous variables / auto-creating all of the stuff that you need to get the code to compile, but are not particularly interested in for the purpose of the test. Really interesting and had not heard of it before. Maybe something to check out as part of the project 365!

Rules for effective teams

This talk was about how teams communicate effectively. You can find the full PDF here. Communication among a team is definitely a super-interesting subject and I really want to dig a little bit deeper into this. Some of the teaching and coaching stuff I got exposed to through my mom (habits of highly effective people type stuff) is really, really interesting and really blows my hair back.

Software gardener vs software engineer as a metaphor

This talk introduced the metaphor of software gardening. You can find the full post here. Personally, I am not too sure about this particular metaphor. I think that craftsmanship is actually much closer (and in my mind craftsmanship sits somewhere between gardener and engineer). I also think that metaphors are a way of getting a particular point across and people then get too hung up about the specifics of them. Having said all of that, of course I love the imagery of tending to gardens.

Big numbers – small numbers ….where approximations matter

This was a talk about how measurement accuracy (as well as floating point arithmetic) may matter a lot in your program and how numbers (e.g. if they are unexpectedly close) may turn out to be negative even though they should not be. This was a good reminder of coding (and testing) for the unexpected code path.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s