Bonus Track (K) 2015
Bonus Track (K)

Session type: Bonus

Software Craftmanship Sessions & Biographies 2015

2015-07-06 23.11.16

Track sponsored by Plymouth University Computing

software-craftsmanshipSoftware Craftmanship 2015 – 2 Day Track


  • Clojurescript Taster Session – Bring the power of Clojure to your browser app – Jim Barritt Thoughtworks
  • Test Driving User Interfaces  – Anthony Williams        Just Software Solutions
  • Only *You* Can Analyse The Code – Anna-Jayne Metcalfe         Riverblade
  • Building systems that are #neverdone – James Lewis        ThoughtWorks
  • Mob Programming, A Whole Team Approach – Woody Zuill, San Diego California
  • Product development in an Unruly Mob –  Alex Wilson    Benji Weber    Unruly


  • Taking back BDD – Konstantin Kudryashov        Inviqa
  • 10 things you need to know about BDD, Cucumber and Specflow – Seb Rose
  • Teaching Agile – Shirley Atkinson   Plymouth University
  • Archipelagos in Git – Matthew Dodkins        Bluefruit Software
  • Waltzing With Branches – Chris Oldwood


jimbClojurescript Taster Session – Bring the power of Clojure to your browser app

Jim Barritt        ThoughtWorks Ltd


Clojure ( is an exciting language that brings the power of LISP to the JVM. It is also possible to cross compile to Javascript and leverage the structure and power of the language to craft front end code.
In this session, through live coding, Jim will introduce you to this exciting world, and give you some pointers as to where to go next, if you want to explore further.

We will look at what is required to get up and running and walk through a simple demonstration application.

Jim has been writing code for many years. He is currently a Principal Consultant for ThoughtWorks.  His passion is the code and systems architectures, helping teams deliver reliably and rapidly.

anthonywilliams-checkTest Driving User Interfaces

Anthony Williams        Just Software Solutions Ltd    


 User interfaces are generally considered one of the harder things to develop
 with Test-Driven Development (TDD). So much so that a common recommendation is
 to make your user interface code as  thin  as possible, and test the layer
 behind the UI rather than the UI itself.
 In this presentation I will show that it is possible to test the UI layer with
 the techniques we already use for backend code, and that this doesn’t have to be painful.

If you truly can get your thin UI layer so simple that it couldn’t possibly
break, it makes sense not to test it. However, if your UI layer is more than
just a few simple controls with minimal behaviour then doing this properly
requires that the  thin  UI layer actually ends up quite complex, as it has to
pass through all the events generated by the UI, as well as provide facilities
for any UI changes made through the UI API. At this point, testing behind the UI
leaves quite a lot of complex code untested, and thus a prime breeding ground
for bugs.

What is needed therefore is a way of working that allows us to bring our TDD
experience to the development of UI code in a pain free fashion. This session
will show that this isn’t just a pipe dream.

Anthony is the author of C++ Concurrency in Action, and director of Just Software Solutions Ltd.

He has extensive experience developing a wide variety of applications for a wide range of systems, including embedded systems, Windows applications and web-based applications.

A strong believer in the benefits of TDD and agile methodologies, Anthony is always striving to find ways to minimize the code that cannot be tested.



agile026riverbladelogoOnly *You* Can Analyse The Code

Anna-Jayne Metcalfe         Riverblade 
So, your  team’s code has quality issues. Big quality issues (and sadly, this is not at all unusual). A decision is made to deploy a code analysis tool to diagnose the problems and work out what to fix.

But who in the team should do it?

Another decision is made. Only *you* can analyse the code, so will have access to a suitable code analysis tool while the rest of the team get on with “real work”.

Is that right? Or should everyone work together to learn how to avoid the mistakes which caused the problem in the first place and write better code in future…while also doing “real work”?

Anna is a C++ software engineer and the founder of Riverblade, a Bournemouth based software vendor specialising in software quality tools and plugging things into the (usually quite crufty) innards of development environments like Visual Studio and Eclipse. She originally started out as an electronic engineer, and even now she has been known to occasionally wave a soldering iron about rather than a compiler.

She is obsessive about refactoring, tweaking and generally making things work better for people. When she’s not doing that, tweeting about all sorts of weird stuff or somehow otherwise mucking about with technology she grows chilli plants, runs along Bournemouth beach and collects Belgian beer.


OLYMPUS DIGITAL CAMERABuilding systems that are #neverdone

James Lewis        ThoughtWorks    


James explores what the increased pace of change in software means for developers writing code *now*. Do we abandon our quest to build quality in? What does it mean for design if we are building software explicitly to throw it away a short time later. Is TDD dead? What does software craftsmanship look like through the lens of replaceable code in small replaceable services?
 In short, what does it mean to be #neverdone?”   

The software industry is changing faster than ever. Now, with microservices becoming more and more accepted as an architectural style, the rate of change of our industry and of the software we write is going to only increase faster.

James Lewis is a Principal Consultant for ThoughtWorks UK. He has helped introduce evolutionary architecture practices and agile software development techniques to various blue chip companies: investment banks, publishers and media organisations. James Lewis studied Astrophysics in the 90’s but got sick of programming in Fortran.

As a member of the ThoughtWorks Technical Advisory Board, the group that creates the Technology Radar, he contributes to industry adoption of open source and other tools, techniques, platforms and languages. For the last few years he has been working as a coding architect on projects built using microservices; exploring new patterns and ways of working as he goes.

 James Lewis has spoken at a number of UK and international conferences. His favorite topics range from domain driven design, SOA and the future of the web to agile adoption patterns and lean thinking. He’s also heavily involved in the fledgling microservice community. He rather likes the fact that he got to describe his take on things jointly with Martin Fowler in an article that is influencing how people see the future of software architecture.

Sometimes he blogs at


WoodyZuill_AOTBMob Programming, A Whole Team Approach

Woody Zuill        Hunter Industries, San Diego California


Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and at the same computer. This is a  Whole Team  approach to doing all the work the team does – including coding, designing, testing, and working with the  customer  (partner, Product Owner, user, etc).   

We have expanded the  team  nature of all the work we do – not just planning, retrospectives, and a daily standup or other meeting – but all the work that the team does.
This is an evolutionary step to the pair programming, face-to-face communication, team alignment, collaboration, and  self organizing team  concepts of the Agile approach to software development.

I’ll share how we’ve been using this as our daily practice to super-charge our development efforts and deliver high value software for over three years. We’ll see what it looks like, the benefits, and how to do it yourself. In our workplace we  Mob Programm  all day, every day, but we’ll also explore some ideas on how you can employ all of the concepts and practices (and get the benefits) of  Mob Programming  in your own company even if you can’t do it  all day, every day .

Woody Zuill has been programming computers for 30+ years, and works as an Agile Coach and Application Development Manager for Hunter Industries, a manufacturer of high quality and innovative irrigation products. His team is the originator of the Mob Programming approach to teamwork in software development, and Woody is considered one of the founders of the  #NoEstimates  discussion on Twitter.



software-craftsmanshipbenji_squareProduct development in an Unruly Mob

Alex Wilson    Benji Weber    Unruly

@pr0bablyfine @benjiweber

Mob Programming is a technique where the entire team participates around one workstation with a single driving seat. It’s pair-programming with more than 2 people.

 We’ll share how Mob Programming has helped us tackle more complex and dangerous problems. We’ll share our positive and negative experiences with Mob Programming – when we think it works well and when it is inappropriate.

Mob Programming is a technique where the entire team participates around one workstation with a single driving seat. It’s pair-programming with more than 2 people.

At Unruly, we are constantly trying to turn up the dial with our XP practices. In the second half of 2014, we started to take the step from Pair Programming on all production code to Mob Programming with the entire team.

Not only has the team been able to tackle more complex and dangerous problems with this technique, but we’ve has been able to involve colleagues with specialities other than software development in our Mobbing sessions – pulling in Product, Infrastructure, and User Experience experts.

However, Mob Programming is certainly not a panacea for badly written code or bad process. It can amplify team dysfunctions as well as strengths. We’ll share our positive and negative experiences with Mob Programming – when we think it works well and when it is inappropriate. We’ll also share how it has changed our team atmosphere, productivity, and effectiveness.

Alex Wilson has been software developer in Unruly’s Product Development team for approaching 3 years, during which time he has had the opportunity to experience and conquer different scaling issues. He takes particular joy in the application of Continuous Delivery principles, pushing the boundaries of modern XP, and recently presented a paper on Unruly’s experiences with Mob Programming at XP 2015.

Benji Weber is a generalist developer at Unruly, where he leads an extreme programming team building a programmatic advertising platform using Java, and a sprinkling of other languages. Benji is enthusiastic about anything that helps build valuable and reliable software fast, including domain driven design, continuous deployment, and infrastructure automation.




konstantinTaking back BDD

Konstantin Kudryashov        Inviqa


 Behaviour Driven Development (BDD) and Domain Driven Design (DDD) seen a great growth in adoption in recent years. We are all creating new practices and tools that try and bring these two very important modern methodologies together. What if we have it backwards and they were actually together all along? What if most of the misunderstandings and challenges we face in implementing BDD are spawned from the very simple mistake of us separating something that was created as a whole?

In this talk we’ll delve into BDD as it was meant to be done from the beginning and look at its very rooted connection with the software design.

Konstantin is a PHP developer that through tools and methodologies got deep into the business analysis area. Currently he is a BDD practice manager at Inviqa Ltd (UK). His current job is a process of bringing agile projects to life through bridging communication gaps between business and delivery teams.



sebrose10 things you need to know about BDD, Cucumber and Specflow
Seb Rose        Claysnow Limited

This session will look at what Behaviour Driven Development is good for and what tools can help. We’ll look at common BDD anti-patterns and myths, leading towards some advice that will help every organisation.   

Behaviour Driven Development (BDD) and Specification By Example (SBE) are quite recent additions to the software development toolbox. Sometimes it feels like we’re using a hammer to drive in a screw, so in this session we’ll explore what they’re good for and when to use them. We’ll also look at what problems they don’t help with and when not to use them.

As you might expect, I’m a huge fan of BDD using these tools when done properly, but I’ve also experienced the pain of organisations who have approached BDD from a test automation perspective. Once we’ve put that anti-pattern to bed, we’ll move on to looking at how to write maintainable executable specifications, organising large suites specifications in an accessible way and some of the technological solutions that can help.

And we’ll have a brief look at some of the features that are shared (and differentiate) members of the Cucumber family.

By the end of this session you’ll know enough to decide whether your problems are more like a screw or a nail – and whether Cucumber/SpecFlow is the right hammer.

Consultant, coach, designer, analyst and developer for over 30 years.  Seb has been involved in the full development lifecycle with experience that ranges from Architecture to Support, from BASIC to Ruby. Recently he has been helping teams adopt and refine their agile practices, with a particular focus on automated testing.

Regular speaker at conferences and occasional contributor to software journals. Contributing author to “97 Things Every Programmer Should Know” (O’Reilly) and lead author of The Cucumber for Java Book (Pragmatic Programmers).

He blogs at and tweets as @sebrose



2015-07-06 23.11.16xlarge_Shirley_Atkinson

Teaching agile – Dr Shirley Atkinson – Plymouth University

Dr Shirley Atkinson will respond to previous tweets about Universities not teaching students about agile with her candid – sometimes we do throw away the book – approach to learning and teaching delivery. She will share her passion for the applied approach of mixing theory and practical activity to ensure Plymouth University students graduate with clear employable skills. Teaching agile, engaging with industry and preparing students for the reality of working life requires good communication and interaction with the industry surrounding Plymouth and it’s environs.

This workshop will also be a call to action. There will be the chance to discuss how industry mentors can help support students in their studies, how Plymouth University is not an academic ivory tower and different ways of helping students learn the skills that make them employable and effective immediately.
Shirley is an academic at Plymouth University with a passion for ensuring industry relevant content is shared enthusiastically with students learning to become computing professionals.  She came to academia late having worked in industry for 15 years as a software developer, business analyst and all round general IT dogsbody.

Shirley first graduated with a first class honours degree in Computing and Informatics prior to working for the NHS Information Authority as a Data Analyst.  She returned to academia full time first completing her PhD in Internet Privacy before working on a number of Post-doctoral projects in E-Safety.  She has been teaching Software Engineering related topics with a web focus part time since 2005 and full time since 2009.

During her time as a lecturer she has taught on the undergraduate project modules linking real projects to live clients, server side coding, exploration of cutting edge web technologies, e-commerce and work based learning.  She has been programme manager for BSc (Hons) Web Applications Development and MSc Computer Science and subject group leader for the SOFT group – the group looking strategically at all Software Engineering topics for the computing degrees.  She currently is programme manager for BSc (Hons) Computing and is leading the Computing At Schools (CAS) Regional Centre.


matthew bluefruitArchipelagos in Git

Matthew Dodkins        Bluefruit Software  @bluefruit

Interactive workshop (no computer)

Anyone who has attempted to cope with the creation and distribution of large quantities of code knows how complex a problem it can become.
 Git helps, but doesn’t solve all the issues and the  blessed repository in the sky  approach starts to break down with many developers all working together on the same codebase.
 Archipelagos are a concept invented by Matthew @Bluefruit to help teams not go completely insane as they try to maintain the quality and habitability of their code.

Anyone who has attempted to cope with the creation and distribution of large quantities of code knows how complex a problem it can become.

Git helps, but doesn’t solve all the issues for you and the  blessed repository  approach starts to break down with many developers all working together on very similar, inter-dependent products across multiple teams. Of course, people willing to review and merge code almost full-time helps, but no-one really wants to do that, and it isn’t right anyway; you need to practise coding to be good at coding, and reviewing code well requires a high level of programming skill.

Git archipelagos  are the way we have solved this problem at Bluefruit. It is a concept I created which helps everyone understand what’s going on and share code which leads to a release, even when huge rafts of code changes are flying around.

The goal of this session will be to provide a concept and set of guidelines for the organisation of semi-disparate groups of individuals who :-
* Need to share
* Desire protection from the uninhabitable and non-functional
* Value creative/productive energy over an abundance of rules and regulations, which only impede you

Hmm, that sounds like a familiar problem, doesn’t it?

I believe there are parallels between this and the problem of co-operation between communities in general. Large/multiple teams of programmers who need to learn to share nicely have an opportunity to explore some of the potential solutions without invoking the wrath of those who hold us in thrall 😉

You will be taken on a short journey of the history of humanity, given an overview of the problems we face and how they relate to software engineering, and together we will discuss some ideas about how we might overcome them.

Matthew is a very experienced programmer (coding since he was 6) having a lot of fun leading an Agile team of embedded software engineers in Cornwall, England.

He uses C, C++, C# and Assembly, and works on lots of different projects, including wireless systems, an electric bike, safe/banking systems, a medical grade water purifier, time code encryption system and many others.

Matthew is currently programming low-power ARM Cortex MCUs and solving complex technical and social problems all day long.




chrisoldwoodWaltzing With Branches
Chris Oldwood        @chrisoldwood

The use of branches within a version control system is a risk management technique. They are commonly used to minimise the risk of unanticipated side-effects when releasing critical changes to production, or to minimise the disruption to developer productivity when making changes to the base product. But branching is not the only means of managing risk and that is what this talk addresses – the forces that drives the use of branches, what are their problems and what are the alternatives.   

Branching during the evolution of a software product, either its over-use or complete avoidance, is just as susceptible to the malaise of the  cargo cult  as many other areas of development. The choice is not always made based on an informed decision with a careful weighing up of the pros and cons and their alternatives, but purely by following what practices the  cool  companies are (seen to be) using.

What is often misunderstood is how the same risks that historically have been mitigated through the use of branches might now be handled via the use of other, non-version-control related practices to ensure stability and productivity remains high in the face of continued change. Whilst there is still a time and a place for the use of branches we will discover when that might be, but equally spend as much time exploring the complimentary practices that help us to avoid their pitfalls.

 Chris is a freelance developer who started out as a bedroom coder in the 80’s writing assembler on 8-bit micros; these days it’s C++ and C# in plush corporate offices. He also commentates on the Godmanchester duck race and can be contacted via or @chrisoldwood.