Way back in March this year I stumbled across SwanseaCon (#swanseacon), a software development conference promising not only interesting talks on “Agile” and “Craftsmanship” but also presenting the opportunity to meet folks like Jason Gorman, who’s blog I happened to read and enjoy a lot.
At just £250 (at the time - early bird price) it was a no-brainer so I got myself a ticket and sorted out most of my travel arrangements. The only thing I had to do, then, was wait till the start of the conference.
The following write-up is my personal experience of the conference and the talks I went to and is by no means complete! Other attendees can surely provide more detail on it and will surely have other views on the talks too - each of the subjects reaches to people in different ways, this is only mine.
It’s also worth mentioning the conference had two parallel tracks.
While more likely to appeal to a wider audience it did mean that you had to choose between them, even if both of them were of interest to you.
From what I heard, the recording of at least some of the talks will be available online at some point in time, which will hopefully address this somewhat.
I’ve linked each of the talks to the corresponding slides whenever I could find them - just follow the link on each of the talk’s title.
Swansea, here I go
Soon enough the day came to travel down to South Wales.
Since the conference started at 10am, and given I was coming from Edinburgh, my best option was to fly down to Cardiff Airport the day before, ride a bus to the city centre and grab a train from there to Swansea.
It took me about 6 hours from leaving home to arriving, but since it was lunch time, I love walking and the weather was fantastic I got myself exploring the city for a while.
Turns out the conference venue, the Liberty Stadium, wasn’t exactly central but you could grab the bus #4 every 15 minutes or so and get there quickly for around £1.50-2.00 (never quite understood the price fluctuations) for a single ticket.
After having dinner I thought I’d go back to the hotel and have some rest so I wouldn’t sleep during the talks next day.
As soon as I got to the venue I was given my conference badge and a goody bag - ooo, presents!
Inside were a number of leaflets from conference supporters, water bottle, mints, a couple of display cleaners and, of course, a USB stick. Also inside was a guide to the conference, listing the majority of speakers and the schedule for both days.
You could treat yourself to tea or coffee and a few biscuits while you did some light networking and waited for the conference to start.
Keynote - “Software Craftsmanship”
Sandro Mancuso delivers a passionate start to the conference, using nothing more than a flipchart and a couple of pens, and definitely sets the tone for the talks that would follow - the craftsmanship ideology - that software is not to be simply delivered to a customer and abandoned but instead nurtured and improved upon.
A blind (and dare I say ignorant) adoption of Agile can often yield poorly developed software that only meets requirements at the surface, but shows it’s true lack of quality by ever increasing costs when it’s out in production or once it needs to evolve in order meet new needs.
The craftsmanship movement aims to take this back and ensure that software is developed to high quality from the start.
From this keynote it was also obvious the theme around TDD as a means towards craftsmanship, but with an interesting twist - that TDD by itself won’t solve all your problems, in particular to the idea that it will drive your software’s design entirely.
This is healthy advice, as any zealotism is incomplete and sure to miss out on the wide range of other techniques we have at our disposal.
When it comes to your design, as Sandro explained, how much you should spend for future proofing your solution should depend on how much you know about it. In essence, the less you know about your problem the simpler your approach should be, and the more you do know about it then the more you can invest up-front in making sure you cover all bases.
He calls this the inflection point, a weighting on how complex your software should be with the knowledge you have at that point in time.
With the tone well set for the conference, you could tell the other talks would be good.
Jason Gorman on “What is Continuous Inspection, Anyway?”
After fighting to find a VGA cable to connect his laptop to the projector, Jason starts his talk on Continuous Inspection.
The talk is centered around the build cycle for your product. The most common being traditionally made up of these steps:
- The whole solution is built
- Tests are run
- The software is packaged up / deployed as appropriate
At any point, if an error occurs or a test fails the build is considered to have failed too and people are notified of the occurrence to fix it promptly.
Jason proposed an additional step to this, a quality gate, placed after the tests are executed, to run a Static Code Analysis (SCA) tool to validate your code. The intent here is to pass your source code through a series of checks that ensures it is up to quality, as agreed to and configured by the team.
The example given uses FxCop, one of many other tools at your disposal to this effect. Jason highlights that using the default settings of such a tool is inadequate - only the team can decide, after careful inspection, which of the settings and checks they agree with before rolling out this step.
In the beginning, the tool will likely report thousands of findings. The team should ignore these in the first stages and act on only new findings to ensure that the software quality doesn’t get worse. When this step becomes stable the team can raise the bar tweaking the tool to perform additional validation. This can be repeated continuously to keep on improving the quality of the software delivered.
He further stresses that, after the tool is in use, ignoring warnings/errors reported by the tool is worse than having no inspection at all - it should break the build just like any other step.
The SCA tool is seen as a means to ensure consistency of the code being delivered, especially when remote teams are involved.
Marcello Duarte on “Understanding Craftsmanship”
The emphasis here is to give meaning to the craft of developing software rather than an empty focus on delivery that is often seen in many businesses.
This is not to say that developers are to write beautiful, art-like pieces of software just for the sake of it but that the developer should take pride in it’s work to deliver software that doesn’t just meet the specification but delivers value beyond it.
TDD is an example to this with it’s Red-Green-Refactor steps, where the tests going green isn’t enough. The software must be continuously improved upon through refactoring.
The premise is then that this allows for building not only long term relationships with customers but a community of professionals that take this forward, improving themselves as a community.
Steve Tooke on “Surrender the illusion of control”
Or “Let It go”, as he also called it.
Steve presents the notion of Connascence, a software quality metric that is not new (in fact, far from it) but that did catch me by surprise.
Behind it are 9 types of connascence, each stronger than the previous, to find out how difficult it would be to change the software while mantaining it’s correctness. What is interesting is that they don’t just identify how coupled the software can be, but present a structured means to correct this as you find your way through each of the types.
Steve takes you through this journey, explains what each of the types means and guides you on how to decouple your software bit by bit.
Chris Cundill on “Scala in GOV.UK Digital Services”
In this talk, Chris shows the audience just how easy it is to get into Scala and start playing with it’s REPL.
Sharing the same runtime, Scala can be easily integrated with Java and offers a strong alternative for writing applications. Examples of it’s terneness and power for dealing with common problems such as manipulating collections (a long time weekness of Java until the recent Java 8) are shown.
Chris also talks on how his team has been adopting Scala more and more lately, with perhaps the negative in that there are far fewer Scala developers out there than there are Java ones, a trend that may be changing lately.
Jiří Knesl on “How to use Theory of Constraints to scale big agile development teams?”
Bottlenecks, or constraints, dictate the maximum throughput of your team.
Jiří stresses the importance of identifying your team’s bottleneck and then using it 100%, otherwise you will lose this production capacity forever.
After this, he guides the audience on how to improve it until it is no longer a bottleneck, at which point the constraint will have moved to another part of your process and thus you repeat the method for finding it and improving it again.
While the talks were taking place, attendees were asked to write any questions that they would like to take forward to the panel discussion on post-its.
These were used to populate a whiteboard for this discussion, taking place at the end the day’s talks. It involved not only the speakers but the audience as well and was open to everyone to participate.
The post-its were grouped together and Adrian Bolboaca read them out in turn. The format was very open, leading to not only interesting but entertaining discussions.
After a good day of talks, there is nothing better than the chance to network with some of the speakers over a drink.
The evening reception took place on the floor above, with view to the stadium’s turf.
The attendees were given vouchers for drinks that they could redeem at the bar. Quickly enough you could see groups of people together continuing the discussion and exchanging different viewpoints.
This was a good opportunity for myself and other two attendees from Fortium to speak with Marcello and talk about TDD practices, as well as other subjects.
The second day of the conference started earlier, at 9am, so I had to take extra care not to be late.
Once again, the day had an excellent start.
Simon Brown, on “Software architecture vs code”
Simon talks on how architecture needs to be easier to understand and communicate. He shows that there is no common, standardized language to describe architecture - a component, for instance, can mean different things to different people.
He also gives examples of how architecture diagrams tend to either be very shallow or drown people in detail, making it very hard to follow especially if you are interested in knowing how a given feature was built and sits along with the rest of the software.
To solve this, he challenges the audience to think outside of the traditional horizontal, or even hexagonal/onion layered architectures, to a more vertical, feature-sliced view. He also proposes a set of terms to refer to each part of the architecture - containers, components and classes - going top to bottom as you navigate into the detail.
This approach may then have an effect on how the tests themselves are structured.
Instead of the traditional testing pyramid, where unit tests are the foundation, he proposes an architecturally-aligned structure where tests are more spread out across classes (the typical unit of your test), components, services and the system itself. This allows you to target tests at more significant blocks of your software and, perhaps controversially to many, expose less of the internals.
On this point, he argues that we should stop making everything public just so it can be tested with a unit test because we can write a higher-level test to exercise that same class or method, along with it’s interactions with other parts of the software as well - in some cases even indirectly testing the integration with 3rd party components, such as databases.
Christopher Batey, on “Software craftsmen need to stop coding so much”
The content of this talk may have caught some by surprise. Chris talks not on software itself, but on giving your technology stack, and future choices, proper scrutiny.
Whenever new tech shows up it can generate an enourmous amount of hype. They can be advertised as being the best, most advanced, more performant solution out there, and they have the numbers to prove it!
Or do they?
As Chris demonstrated, these numbers are more often than not misleading. If you look closely, you may find out that your new shiny tech is, in fact, not optimal and it’s metrics not representative of real-world usage at all.
Before rolling out any new piece of tech it needs to be exercised against worst-case scenarios, with as many variables in the mix as possible - network latency, disk failures - the lot. You want to find out if your software can live with these problems before your customers find out.
This is extremely important to anyone building a new software solution from scratch, such as in greenfield projects, or people considering replacing parts of their technology stack.
It needs done early because changing any technology later will cost the business a whole lot more.
Alexandru Bolboaca, on “Usable Software Design”
Alexandru starts on a lighter tone, presenting a few examples of bad product designs such as the tea/coffee pot for masochists (do have a look online for this and other hilarious examples).
His emphasis is on the importance of writing and laying out software in a way that developers themselves can easily navigate and understand, something that is not given the right importance often enough.
As an example, even a well designed file structure for your project can give out hints to anyone looking at the source code about what it is and what it does. Small details like these can greatly improve the rate of learning of your team, which in turn makes them more efficient and less prone to make errors.
The code itself should be consistent, clean and cause the reader “minimal surprise”, and can be coupled with tests or even comments to further describe intent and usage examples.
In some instances, he notes it’s best not to use some features of the programming languages themselves if the team is not familiar with them as that could generate more confusion.
Adam Tornhill, on “Treat your Code as a Crime Scene”
In this talk, Adam gives us a look on how much information you can extract from your commit history. As it turns out, it’s a lot.
In a practical example, Adam shows us that if you have a set of source code files that are more subject to change than others then it’s very likely that the majority of bugs you have will originate from these. Target your efforts here and you may be improving your software where it needs it the most - reminds me of the Theory of Constraints, only for code!
With this same approach you can have an insight on many other aspects of your code base too.
For instance, do you have many files that perhaps no one else touched apart from a developer that just left the company? Then that means that software has been abandoned and you may have lost it’s domain knowledge along with it. With access to this information you could have preempted these kind of events and planned accordingly.
It was impressive the number of different conclusions Adam was capable of coming up with nothing more than a source code repository and it’s history. This is very powerful and can prove extremely useful - do have a look at his website to find out more.
Christos Matskas, on “Common mistakes in TDD - can you guess?”
There was a lot of focus on TDD in this conference, but Christos has perhaps presented the most realistic view on it.
Apart from talking on some common mistakes such as not refactoring, having too much setup on your tests and asserting too much per test, some problems that Christos raised are not as obvious and probably not popular with purists.
Testing too much, for instance. There is limited benefit in testing 3rd party components/libraries as those should have been tested already. If this is not the case then you should be using an alternative.
He also notes the simple fact that tests cost real money, and therefore our testing effort should be made were it represents most value. Often times, also, people don’t use the right tool for the job and may end up damaging their software design in the process.
These mistakes are felt through experience and you could tell Christos had been there before.
Adrian Bolboaca, on “Legacy Code is Fear”
Ah, the mythical legacy code beast. Unloved and mysterious, everyone is quick to jump on it and want to refactor it all - to “make it better”.
Adrian, however, is much more pragmatic about it.
He talks that you should never change code unless you have a reason to, and that reason is to fix existing problems or add a new feature. And if you have a really important piece of functionality you will want to have a test framework around it to make sure it doesn’t fail.
When the time comes to have to change any code, though, you’re in a tight spot. It has no tests - how can you guarantee that you won’t break anything else?
Well, realistically, you can’t.
What you can do, though, is start by writing end-to-end tests and delve in with more targeted integration and unit tests as you build your understanding of the software. By the time you do change it then you will have much better confidence that your new code works, and that everything else kept on working.
His approach is all about minimising the unknowns, the source of fear, and it may be that the team itself may need to learn new tricks to get there, be it learning about a new language or technology.
This is an investment that needs done, but will pay off dividends in the long run.
Unfortunately, this is where I had to cut off to catch my flight back home, meaning I missed the opportunity to go to one last talk and the closing keynote.
If anyone wants to add to this write-up I’m more than happy to do so, just ping me on Twitter (@ruimourato) and we can discuss.
No doubt this was a great conference. You could tell the speakers and the audience were truly passionate for their craft.
Great work from the organizers in setting up SwanseaCon 2015 to run so smoothly - I don’t remember having experienced any kind of hickups which is no easy feat!
I can’t stop myself from commenting on the fact that a lot of the speakers were from the Codurance team. While this is in no way a bad thing it may give place to a more biased/likeminded environment, although to be fair any appearance of the company logo or name was subtle and the team is indeed excellent.
Still, it would be nice if the SwanseaCon organisers had a range of speakers coming from more diverse backgrounds to avoid this - something to watch out for next year.
Perhaps because of this there was maybe too much focus on TDD. Sure, TDD is excellent, but craftsmanship can’t be about a single methodology. There is no shortage of other subjects to go through.
Would I repeat the experience? You bet!
It is a busy time of the year with competing software conferences running across all parts of the country, and indeed outside the UK. Company employees and independent professionals will likely only go to one of these unless they are promoting their own business, but I’d say SwanseaCon is still in a good position if it keeps itself competitive.
Thanks for reading, and here’s to more of SwanseaCon in 2016!