Software craftsmanship 2013 – a retro

On Friday, I took a day off work and went to the software craftsmanship conference 2013 edition held at Bletchley Park. This was very well organised by the guys at Equal Experts. Here is a quick summary in true retrospective style of how it went …

….what went well?
In general, it was an awesome day out! The Bletchley Park setting felt very fitting. I also really liked the hands-on approach of the conference. The emphasis on coding workshops meant lots of interaction with other people and the different kinds of sessions on offer also meant interaction with different kinds of people!

….what went badly?
I can’t think of anything that went horrendously badly …but… I was a little disappointed with the lunchtime tour: They had some trouble with the regular tour guide and a very nice chap was asked to lead the tour at the very last minute. Unfortunately, because of this, it focussed very much on the bits that are very much popular knowledge (Enigma, Turing, Colossus, etc.).

I suppose I could have gotten a bit more of a computing history fix by making it to the later tour of the national museum of computing, but I had to catch a train back. Oh well. I’ll come back as a proper tourist some time!

….what can be improved?

There are three things that I can think of that can be improved – one for me, one for the organisers and one for the talks themselves:
To be more effective at this kind of workshop, I really need to have a better dev setup on my surface. The surface as a machine is powerful enough, but at the moment _I_ take too long to spin up Visual Studio and get the right kind of project, set it up how I want it, where I want, choose source control, etc.

There were – I think – seven sessions to choose from for the day, but at most you could choose two (a morning session and an afternoon session). While this kind of makes sense (a workshop takes a fair amount of time after all), it is a real pity that I missed out on some sessions that I was really quite interested in (TDD in the morning and callback hell in the afternoon).

Both of the sessions I went to started with the words “this is the first time I’m doing this session and you are my guinea pigs”. This is fine of course and I definitely learnt a lot in the sessions. In terms of structure both of those sessions will definitely improve after a couple more iterations.

Right – now that we have done the short Agile version of the conference, I’ll do a quick summary of each of the sessions:

In the morning I went to Phil Parker‘s “Crackathon – securing your craft” workshop.

This was a great session where Phil had prepared a deliberately vulnerable website for us to dig into and exploit: Before I go into any more detail, I should say that this is definitely outside of my normal comfort zone (server side C++) and so my comments may well be a little inaccurate when it comes to describing the vulnerabilities themselves. We split into teams (five or so to a team), got given the site address and were then asked to email loopholes, bad security practices, etc. to a “bounty Email address”. Most importantly, sweets were awarded for finding a vulnerability. Phil then did a great job of walking through the Emails, explaining the various loopholes we found, describing defences against the attacks etc.
A couple of ideas for the next iteration of this session would be:

  • Some documentation on the vulnerabilities and defences against them (I had to rack my brains to come up with the bits below and I’m fairly sure it’s at most half of what we went through). Phil mentioned that he had set up some unit tests to ensure that the site still contained the vulnerabilities so an awesome way might be a copy of the site together with the tests. (I appreciate this is potentially a lot of IP to give away).
  • From around halfway through the session I found myself torn between wanting to keep digging for more exploits and listening to Phil’s explanations. Maybe a way of structuring this into distinct phases would be cool?
  • Dedicate a part of the session to actually implementing defences. (You’d probably need a longer session for this.)

Phil highly recommended the OWASP website and in particular the top ten section of the website. A lot of the exploits that we talked about (SQL injection, cross site scripting, sensitive data exposure / information leaking, unvalidated redirects and forwards etc.) came from the website. Others (e.g. password storage – salting & hashing, Wifi information harvesting with pineapple and Mac’s promiscuous mode, Email authenticity) were a little more general. Quite a number of these I hadn’t heard of before such as using unvalidated redirects and forwards as part of the OAuth standards and XML based DOS attacks. Finally, we talked about some tools such as the OWASP Red Zapper which can be used during normal testing to help with spotting some of these vulnerabilities.

Overall a really great session which I thoroughly enjoyed!

In the afternoon, I went to Jason Gorman‘s “Test-driven object oriented design”.

This was a talk about how the test driven development approach affects your OO design. Really, this was probably a bit too much of a jump in the deep end for me. Effectively, I tried to learn both the TDD and the OO design effect in one step. So – to really benefit from this talk, I should have gone to Emily Bache’s morning session on TDD.

Still – there was a lot to learn here and it has definitely moved the TDD literature on my reading list up a notch.

The approach advocated by Jason seemed to be to move from user story to “given when then” acceptance tests (maybe implemented in cucumber) to an object hierarchy.

(Can you tell I did a fair amount of googling around to make sense of this later on?!?)

To arrive at the object hierarchy, he advocated a two-step approach. Figuring out the actions required (in the passive), then figuring out the actors associated with these actions.

For each of the objects unit tests would then be written from the outside in, eventually arriving at a chain of unit tests which make up the acceptance test.

Jason illustrated all of this within the context of a particular user story.
In the workshop part of the talk, we then went through an additional user story with a partner taking it from the user store to the acceptance tests to a simple code implementation.

Beyond all of these new, sexy and exciting ideas & techniques what struck me was that the process felt a little artificial:
In the workshop the user story was completely static because there was no interaction with a product owner. We were our own product owner and really tried to imagine what the product owner might have thought of as important. To me, this really underlined the importance of interaction with the product owner in determining key design features, incidental portions of the design.

Having sounded that cautionary note, we did manage to get through the user story (with a little bit of struggling and a fair number of iterations). In the end, it was good to see how the various techniques fit together.

All in all a great conference. I would thoroughly recommend this to anyone interested in (various forms of) craftsmanship!

Advertisements

Review: “Apprenticeship patterns: Guidance for the aspiring software craftsmen” by Dave Hoover and Adewale Oshineye

(Goodreads link here; free online version by O’Reilly here)

I always find pattern books a weird mixture of

  • lots of useful information which I can’t wait to try out,
  • an overload of information where I’m desperately trying to hang on to what I can

This normally leaves me in a slightly muddled state.

As much as review, I will try to create some order out of chaos or as Daniel Kahneman might put it “satisfy my human desire for consistency”.

This is the first software craftsmanship book I have read. It was first suggested in some discussions of the LSCC meetup group and it then swiftly made it on to my reading list.

Since this was my first formalish introduction to software craftsmanship, I was glad that this book does a great job of explaining (their view of) craftsmanship.

There are – of course – some controversies in the general blogosphere around craftsmanship:

While I don’t know enough about the wider craftsmanship community or indeed the software development community to comment much on this, the view in the book seems to be very inclusive (i.e. against divisions between craftsmen on the one hand and engineers on the other) and value based.

I very much agree with the values and philosophy that seems to underlie the patterns discussed in the books and would summarise them as (some related patterns in [] brackets):

  • Take pride in and enjoy what you do

    [Unleash your enthusiasm; Nurture your passion; Sustainable motivations]

  • Learn for life: There is lots to learn and practice. Everyone has the aptitude to learn and practice

    [Practice, practice, practice; Expand your bandwidth; Read constantly; The Deep End; Confront your ignorance; Breakable Toys]

  • Individuals are responsible for their own learning and for structuring their learning

    [Draw your own map; The Long Road; Record what you learn; Reflect as you work; Create Feedback Loops; Learn how you fail]

  • We are embedded into a community of professionals

    [Be The Worst; Find Mentors; Kindred Spirits; Rubbing Elbows; Share what you learn]

(Of course the craftsmanship community would summarise their views in their manifesto slightly differently themselves.)

These ideals are very inspiring for me and are the kind of values that I would like to align myself with.

The main part of the book – the patterns bit – is based around strategies to help achieving these ideals. As such this is not really a software engineering specific book, but could be used by anyone with similar outlook, aims and struggles.

For me, the most relevant patterns (the ones I’m itching to try out) at the moment are:

  • Breakable toys

    Breakable toys is a way of having toy applications and implementations of technologies you come across and problems you’d like to have a go at solving. It is a way of getting experience without having work / production (quality, criticality etc.) associated with it.

    For the last couple of years, I have used the main application ecosystem that I work on as my stomping ground: Whenever I learnt something, I immediately thought “how can this apply to that application” and “where can I safely implement this”. (Of course not nearly every idea made it into the released final product…). Over time this also guided what I considered to be interesting problems.

    In future, I would like to decouple this a little bit. Build the toy independently of work technologies and considerations first. Then think about whether there is any use for it in terms of work. This approach has a couple of advantages: Those breakable toys are more “my toys” (rather than just stuff I worked on) and they stay mine. It will also expand my bandwidth (play around with node anyone?) and so, ultimately, give me a more rounded view of development technologies.

  • Kindred spirits / Find Mentors

    In my current role, I get to interact with a great bunch of talented, enthusiastic and motivated developers. I have learnt a lot from these guys. Up until now they have been my main source for kindred spirits and mentoring.

    However, their background and what they work on is of course very focussed on enterprise application technology and also the particular business domain (i.e. finance).

    In future, I hope to expand my horizon by finding a wider net of kindred spirits and mentors.

    (That is why the goal is to go to at least one software related talk / meetup / roundtable-y thing a week in diverse communities.)

  • Read Constantly / Reading List

    During my MSc and when I started my job, I rarely stopped reading finance or technology related books. These were mainly on the primary topics I dealt with at the time (stochastic calculus, fixed income, derivatives valuation on the finance side and Effective & Exceptional C++, design patterns, boost, SQL server programming, agile principles etc.).

    As I grew more comfortable with these ideas, my reading slowed a little (I guess the authors would call it “retreat into competence”).
    Now, as my interests expand, my reading list is expanding at quite a fast rate.

    (So there’ll be plenty more reviews like this one I guess.)

  • Expand your bandwidth

    I guess this is the underlying theme of the two previous points. The key point here is for me to take responsibility for my learning and not just to wait until learning opportunities magically appear.

  • Record what you learn
    At the end of the day, the thoughts behind “Record what you learn” are why I have started this blog. Since there is so much to learn out there, I need a record keeping mechanism as well as a scratchpad where I can digest and grapple with new ideas.

Anyway, back to the book review: The patterns are presented in a useful straight to the point format: first giving a brief explanation, then some wider context, some immediate actions, as well as related patterns.

For all of the positivity in the rest of the review, let me be a little more critical for a moment:

  • “New” material

    As the authors themselves admit, the idea behind patterns is not to be “new”, but instead to be tried and tested solutions for common problems. This is definitely true here: I found myself more reminded of things I had done before and wanting to apply those to my current situation.

  • Patterns as a language device
    Patterns of course have a much broader history than the GoF book and there is a whole pattern movement out there. In my mind the benefit of the design patterns has always been to enable communication with others as well as facilitating your own thought process (being able to give something a label as a shorthand). I am not sure whether this communication aspect will really be something I’ll make use of. I can’t really see myself going to my boss or co-workers and talking about “the long road” versus “a different road”. This doesn’t mean the underlying ideas are not useful, but I am not sure (yet) about using these shorthand labels.
  • Stretching the craftsmanship analogy

    I like the craftsmanship analogy for software (or general life). In some senses, they remind me of the four stages of competence. After a little while though the metaphor wears a little thin: rather than just looking at the main point of the metaphor the authors sometimes rely on incidental aspects of it.

However, even given those (slight) negatives. This is a great book to read, if you are looking to

  • re-awaken your enthusiasm for programming
  • critically re-examine your current practice
  • you are short of items on your reading list

    (reading through this my “outstanding” reading list increased substantially)

An Evening At The London Software Craftsmanship Roundtable

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:

  • Socrates UK

    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!

  • Apache camel

    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).

  • Measurement

    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
    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!

Review: “The Node Beginner Book” by Manuel Kiessling

I have recently started dabbling with Node.js. A local meetup I stumbled across called stack kitchen is to blame for this dabbling:

Before the talk, I felt a little self-conscious about my node & javascript skills and went looking for somewhere to get the basic low down on node.

Being a lazy Google-user, I did not make it far down the list of results (or even try a very specific search) and used this tutorial.

About halfway through, I realised that the site was actually plugging a book – so I bought the book and worked through the rest of the book.

There are of course lots of other tutorials to choose from out there – probably because node is the flavour of the month (or given how hip I am the flavour of last month…).

Other tutorials and node resources are for example:

  • This focusses on node as a script host, not so much on the typical use case as a web server.

    I liked that it gets you started quite quickly and also mentions some important main features (interactive shell, packager manager, modules, callbacks). A good quick start guide if you want to start hacking things together.

  • This is more of a blog than a tutorial. It covers lots of different stuff. Probably not a place to come back to later, but not for finding your feet.

  • Felix (much like Tim who is man behind “How to Node”) is one of the early contributors to node. This website is really several guides in one: a tutorial to get you started, a guide on the community, a style guide and a guide on how to convince your boss (aka when to use node).

(This list was compiled on the couch on a lazy Saturday morning. So… let me know about other cool Node resources!)

How do you choose between those and this book?

If you’re like me, you’ll just take a chance on the first one you stumble across, but “The Node Beginner” book might be for if you…

  • …are interested in using node on the web server
    Almost all of the book (apart from the initial hello world example) is organised around a couple of (toy-like) web server use cases. There is e.g. no mention of using the node shell or script / parsing like examples.
  • …have some experience in programming, but not really in javascript

    This book assumes almost no familiarity with javascript. I reckon you could probably get away with knowledge of any OO language. Some server side exposure might help. (I have played around with javascript mainly for mobile and client side toys in conjunction with frameworks like knockout and even knowing only these toy use cases I found some of his explanations a little long winded.)

  • …are interested in different components of a web server and how they hang together

    The separation in to different modules such as the server, the router, the request handlers and view generation was one of the parts I enjoyed the most. While this is well covered, familiar ground (Skonnard e.g. covers similar handling and routing for WCF RESTful web services here), there was very much a beautiful simplicity to the toy implementation here.

  • …like a blog post writing style

    Writer’s style obviously comes down to personal preference, but I really like the style of the book. While sometimes a little long-winded, things are explained in a clear and logical way. Steps are laid like the thought process of somebody developing their first node application. For me this kind of approach fits very well.

Beyond this (and in the interest of adding yet more bullet points), there were some particularly interesting insights here for me:

  • …how strikingly easy it was to set up a simple server

    You literally need nothing more than node installed and the six line long javascript sample on the node.js website. Wowsers.

  • …how you then still need to hack your server components together
    There was a fair amount of reinventing the wheel in the book. However, to appreciate how much you need to really reinvent the wheel and how much was just a teaching device, I really need to dig a little deeper into existing node packages. Initial impressions are that there are loads and loads of packages.
  • … execution model

    This is one of the things I really still need to get my head around. I get the basic description in the tutorial of the importance of non-blocking operation and a single threaded event loop ….but… I really need to understand this a little better, e.g. how things are executed asynchronously. This seems like quite a good place to start – contrasting node with IIS&WCF.

  • …the ease of use of package managers

    I know this is the order of the day for almost any programming language out there now, but for C++ devs, this is still a big leap. I know Microsoft has expanded NuGet for native use, but because of C++’s reach across different compilers I’m a little sceptical of the widespread adoption of this.

For me, the next stop on the road of learning of node is “Hands on: Nodes.JS” by Pedro Teixeira.
This book comes bundled with the “Node Beginner Book”. Having read some of the first chapter (and glanced through the table of contents), this feels much more like a “grown-up” book. Lots of references to different patterns etc.

The plan is to also start building some breakable toys in Node. (Can you tell I’ve been reading a book about Apprenticeship patterns?). Those toys might make a good first use for my blog github repo.

ReadingList.emplace_back(“Elements of Programming”)

I’m currently writing up my first “proper post”. Something which actually has some content. It’s going to be a review of some of the Going Native 2013 talks you can see over at Channel 9.

While reading up on the various talks and materials surrounding the talks, I came across a comment by Sean Parent recommending Alexander Stepanov’s & Paul McJones’s “Elements of Programming“.

Having watched the Stanford lecture in which they describe the book, I am quite intrigued by the approach and the book has definitely made it on to my reading list.

The idea here seems to be to foster greater and deeper understanding of programming through linking programming with mathematical theory. In particular, the assertion seems to be that programming is a continuation of the practical application of algebra. (…although not having read the book yet, I could of course be totally wrong.)

On the Amazon reviews (as well as the audience Q&A in the video), there appear to be some discussions whether this truly covers new ground in computer science theory. Given that this is an area where I don’t have much prior exposure, there is only one way of finding that out. Read it (and get out pen & paper for some working through it)!

PS: I’ll link to my Amazon reading lists as soon as I have a moment tomorrow.

A good old fashioned intro

In this blog, I’ll be static casting some random topics: I’ll cast off all safety catches afforded by normal reality and twisting topics to fit into my twisted reality. That’s at least what I’d like to think. Most likely, I’ll just repeat conventional wisdom spouted by everyone else in yet another place.

Enough of the fluff.

The inspiration behind this blog is among other things this blog post by Jeff Atwood.
The other reason for starting the blog is that I need somewhere to store my stream of consciousness for all of this computing stuff. Bookmark collections, dropbox folders etc. just don’t seem to do it for me. So maybe something more stream-like will do.

Topics here are likely to include little series & posts on:

  • Containers
  • Algorithms
  • Some other code katas
  • Multi-Threading
  • UI & Graphics work with C++
  • C++ libraries
  • Financial libraries
  • Unit testing
  • Design patterns (both OO and enterprise)
  • T-SQL
  • SOA & web services
  • Mobile & web development (particularly hybrid / HTML & javascript based apps)
  • Agile practices
  • Visual Studio & TFS

Ironically (and in a half-hearted gesture of neutrality), any code which I’ll link to / mention in the blog will be hosted on a – currently very empty – Github repo and not in a TFS service.

I’ll also try to review (semi-interesting) books, videos and talks.

Altogether, I hope to post at least once a week. Looking at this list, it’ll take ages to get anywhere at that rate though. Never mind – maybe I’ll just ignore all of the above and ramble about photography, running and climbing. Some of which I sometimes indulge in in my spare time.