iTake, Bucharest: A Crash Course in Software Craftsmanship

This week I attended the curiously titled ‘itake unconference’ in Bucharest. It covered a broad selection of topics, but all fell under the loose umbrella of the ‘Software Craftsmanship’ movement. The movement itself is another broad topic, something in the realms of the ‘Agile manifesto,’ more of a summary of ideals and ideas, than a prescribed set of practical steps to take. These include:

• Creating well-crafted software, not software that is purely functional. What this means is a big subject, but the point is to aim for it and care about it.
• Proactively making changes for improvement and not just responding to requests.
• Building a community of professionals who help improve each other’s own knowledge and practices.
• Not only collaborating with customers but create productive partnerships with them.

In terms of the conference, this meant a lot of talks on testing, documentation (my own area of passion), best practices, education and self-improvement, data analysis, and security. The program included longer sessions to allow for in-depth explorations of topics and regular breaks for that most important of tracks, the hallway track.

In fitting with the nature of communication and collaboration, the software craftsmanship community has meetups all over the globe mixing talks with lean coffee sessions, katas, dojos, and other structured events. At first, the structured nature of these events can seem fussy or unnecessary, but experience has taught me that the structures help the less experienced or confident get involved with confronting experiences.

Here are a few select nuggets of information I picked up along the way.

Maintainable Tests

The basic principle of writing maintainable tests is to keep them as simple as possible so they are easy to write, maintain, and understand. Reduce the detail of the specifications for each test to what is needed for inputs, outputs, and processes.

You can find numerous articles covering the subject with a quick visit to your local friendly search engine, and example tools that encourage you to write such tests, like Cucumber and its Gherkin syntax.

Behavior Driven Development (BDD)

Fitting nicely with maintainable tests is BDD, or developing with the user in mind and ensuring that you consult all parties and stakeholders to add value and expertise. You have likely encountered its principles through processes like writing or following user stories. BDD considers development complete if it matches that user story and has a test that proves it does.

It’s an extension of ‘Test driven development’ (TDD), which focuses more on development that matches concepts you test, instead of user stories. You should not consider development complete until it passes a test.

Putting the Science Back Into Computer Science

Felienne Hermans’ keynote was a wonderful encouragement for introducing more structured experimentation into your development work and education, and specifically about teaching coding to children. The talk covered following the scientific method to analyze problems, ascertain theories on how to solve them and gather data to prove or disprove the effectiveness of the changes you make. Her presentation isn’t online (yet), but here are sketch notes from an attendee.

How to Interact With Your Colleagues

As software craftsmanship encourages collaboration, this can mean a lot of communication and attempting to understand each other. This is especially true in international teams where there can be a lot of differing cultural backgrounds and interpretations of conversations. This can involve listening carefully, removing emotion from your interpretation, and taking a moment before responding. Patkós Csaba also mentioned an intriguing theory that the reason we are often so ineffective in meetings is due to boredom, as when we listen, we use less of our brain capacity than when we read. Patkós hasn’t yet put his presentation online but recommended two books if you are keen to learn more. Thinking, Fast and Slow by Daniel Kahneman and Steal the Show by Michael Port.

Security Testing Strategies

Application security has never been more present in the news and relevant, with major companies regularly revealing major hacks and leaks of information. Dan Billing’s talk was a revealing romp through how easy it is to reduce potential attack vectors, mostly through good communication (there it is again) and thinking more like ‘bad actors.’ One of his tips was especially useful, staying ahead by rethinking your user stories to consider how they could be exploited.

Mob Programming and Lego

In the final talk of the conference, Joe Wright explained how mob programming had helped his development teams reduce faulty code and improve their aging monolith. Mob programming is an intriguing concept where developers form small teams and code together, one typing, and the others giving directions and ideas, with roles changing regularly. It can take getting used to, and raised a lot of questions, but could be worth trying for particularly difficult coding problems. Joe also shared a tip for showing how much work a team had completed by using Lego bricks of different colors to represent bugs, features, etc. He mentioned it was a simple way for team members and managers to see what types of work was dominating, and make the necessary changes.