2018 Videos

Talks from our conference, with thanks to our amazing speakers.

Opening Keynote - The Craftsman's Oath

Robert Martin

We are programmers who aspire to be worthy of the title of Craftsman. So what is a software craftsman? What promises do software craftsmen make to their fellow craftsmen, their employers, and society at large? In this talk, Uncle Bob presents, for your consideration, an oath for all who desire to serve society through the design and implementation of computer programs.

The model-code gap

Simon Brown

When we're having an architecture discussion, we'll talk about abstractions, using terms like component, module and layer. These abstractions reflect our mental model of a software system, which are useful when describing our architectural ideas and intent. These same abstractions don't typically exist in the programming languages we use though. There's no layer keyword in Java, for example. To implement these abstractions, we need to use a combination of the constructs available in our programming languages; such as classes, interfaces, objects, functions, packages, namespaces, files and folders. In many cases, the code that is written doesn't end up reflecting the model. This is the model-code gap. The model-code gap manifests itself in a number of ways. In obvious cases, the code doesn't match the architecture diagrams. Sometimes the problems are more subtle though. This session is about the model-code gap, and particularly how it relates to applications that are built from a single monolithic deployment unit. Regardless of how we choose to structure our code (layers, vertical slices, ports and adapters, etc), our best design intentions can be destroyed in a flash if we don’t consider the intricacies of the implementation strategy. The devil is in the implementation details.

Crafting monoids in your software

Cyrille Martraire

You probably cannot imagine that Monoids (not monads) are so simple maths creatures that you can understand them in just a few minutes. But you probably don't imagine either that they can help you craft elegant and powerful code that pushes composability to the max. And composability is good! Through many examples and a demonstration with glasses of beers, you will discover how monoids are an important tool in your toolbox. Even in languages like Java or C#, this talk will influence your coding style forever!

Effective Technical Agile

Emily Bache

Coaching How does a Technical Agile Coach improve work in a development team? For years I’ve helped set up Coding Dojos as a space for teams to learn the theory and practice of TDD. All too often the initiative fizzles out and the dojos stop happening when I’m no longer there. Without technical practices like TDD and Refactoring, agile adoptions can also fizzle out. The latest research into DevOps shows that organisational culture, team collaboration and learning is really important for success. Recently I have been using Mob Programming as a way to improve team culture and spread healthy technical agile practices in a team's production codebase. I've found that this in combination with shorter dojo-like daily learning sessions is really effective at changing behaviour. In this talk I'd like to share my experiences of what I've found to work in real teams.

A Case For Outside-In Design

Sandro Mancuso

For a few decades, one of the most common approaches to software design is to first focus on the domain model (application layer), then persistence (data layer) and finally the user interface (presentation layer). But what are the pros and cons of this approach? Are there other alternatives? Are they viable? In this presentation, Sandro will be talking about different design biases and the impact they have. He will then focus on Outside-In Design, explaining how our domain model can emerge and evolve when driven by the needs of external systems or users, avoiding speculation and wasted effort.

A Bluffer's Guide to Technical Debt for other people

Steve Freeman

We need to explain Technical Debt to people who are not technical, partly so that they can make better choices because they understand the real trade-offs, and partly to so that we understand it better too. Some of the tension between trying to get product out and developing something you can live with is an essential feature of trying to do anything new, but some is the result of a mismatch of understanding between Product and Development. The metaphor of debt does not really convey the risks that arise from poor technical quality. Instead, I will introduce some other metaphors for looking at technical risk that we think match the problem more effectively, and propose some strategies to help product and development teams approach a solution. This is joint work with Chris Matts.

Strategies For Working With Legacy Code

Rachel Davies

I love working with legacy code! It's great fun to dive into a system that we didn't write and figure out how to improve it. Last year, I jumped at the opportunity to work with a startup on a Ruby on Rails code base where developers had left and business users needed support. As I dived down into the code, there were a few surprises lying below the surface but my experience was not a miserable one. I enjoyed the challenge of an incredible learning experience. I'll be sharing my key insights from this project in my presentation at SC London. Come along to this talk to hear some practical strategies for getting to grips with an ageing code base while setting realistic expectations about what's possible.

Panel Discussion - Technical Practices

Robert Martin, Sandro Mancuso, Emily Bache, Alex Bolboaca

The panel is going to discuss the importance of Software Craftsmanship and technical practices. What are the technical practices development teams should adopt? Why should they adopt? What is the business value they bring? How to create a culture of learning that is embraced by developers and business?


Kevlin Henney

The world of software development has changed so much and in so many ways since 1968 that it's difficult to imagine what we could learn from then, but it's learning rather than imagination that's the constraint. There was no shortage of imagination, insight and inspiration in the 1960s and 1970s, and in many ways the apple of 21st-century software development has fallen disappointingly close to the tree of the past.

Raising the Bar: Out of the box ideas to improve software development

Alex Bolboaca

As a child of science fiction, the words that captured my imagination from the Manifesto for Software Craftsmanship were 'Raising the bar'. How can we raise the bar? What is the realm of possibility? What is beyond what we imagine possible? In this talk, I will go through a number of ideas that can help raise the bar. Here are a few:

  • Reaching out to scientists
  • Turning back time to fix our design mistakes
  • Mixing software development with other domains: usability, material physics, or maths
  • Get inspired from the work of other designers
  • Fundamental properties
My hope is that these ideas will capture your imagination and you will help improve, test and implement some of them.

Code Review Best Practices

Trisha Gee

In this talk, Trisha will identify some best practices to follow. She'll talk about what's really important in a code review, and set out some guidelines to follow in order to maximise the value of the code review and minimise the pain.

Being Unruly - an XP journey

Steve Hayes

These days it's relatively easy to find accounts of what it's like to adopt agile for the first time: things to consider, suggestions of what might go wrong, and promises of what will be better. Less so for Extreme Programming (XP), whose star has waned (but perhaps may be waxing again). However, it's much more difficult to find accounts of what it's like to have applied agile practices, particularly XP, for protracted periods in growing organisations. As usual, while there is enlightenment in the journey, nirvana is elusive. Steve will talk about XP as it's practiced at Unruly, a video marketplace founded on XP principles more than a decade ago, and which continues to build on those principles - across the organisation, but particularly in the software development teams. Pairing or mobbing is the norm, continous delivery and test-driven development are simply givens, and decision-making is distributed, combining both top-down and bottom-up elements, but there are still plenty of challenges. Steve will be reflecting on how Unruly compares to other organisations and teams that he's encountered in his 30 years of software development, both agile and not, and the aspects of the process that are still evolving at Unruly. Hopefully you'll be inspired to change, regardless of your starting point, and you may also learn a few things you'd like to avoid in your journey. Steve's XP journey officially began when he was asked to be a reviewer of the first edition of Extreme Programming Explained in 1999. After many years of encouraging teams to be more agile (with varying degrees of success), the journey has taken him to Unruly, where he has been CTO since September 2017. Steve was also a co-founder of Cogent, an Australian company founded on the principles of transparency, collaboration and software craftsmanship values. In between, he's worked in investment banking, a Silicon Valley startup, and a variety of small companies and consulting commitments.

Panel Discussion - Modern Software Companies

Michael Feathers, Mashooq Badar, Rachel Davies, Steve Hayes

The panel will discuss how modern software companies look like and how they should be structured. Flat structure? Decentralised decision-making? Empowerment? The panel will share their experience in how they've been running their own companies and also how they are advising their clients.

Nature of Learning

Mashooq Badar

Learning is a part of our survival and key to professional success. Understanding its nature helps us to become better learners. In our industry, where technologies and practices evolve so fast, effective learning is an absolute necessity. I will explore the nature of learning from learning styles to the tools that we use to learn. I will discuss our motivation for learning and the importance of active learning. It is too important for us to simply stumble through, our approach to learning must be deliberate.

Sub-second acceptance tests

Aslak Hellesøy

As a programmer, I make hundreds of mistakes every day. I only check a few of them into source control because I'm able to discover my mistakes within seconds. Fast unit tests uncover some mistakes, but to get maximum confidence I rely on full-stack functional acceptance tests as well. Over the past couple of years, I have discovered techniques for making functional acceptance tests run in milliseconds. The effect on productivity is almost unbelievable. In this talk, I'll demonstrate those techniques. I'll also explain how to organise functional tests so they can be run in different configurations, optimised for confidence or speed.

2017 Videos

Talks from our conference, with thanks to our amazing speakers.

Software Craftsmanship - 8 years

Sandro Mancuso

The software craftsmanship movement started 8 years ago. What happened since? Has anything changed? Where is this movement? What is Software Craftsmanship anyway? In this session Sandro will be talking about the past, present and future of the Software Craftsmanship movement and how it is changing the way developers and companies think about software.

What we talk about when we talk about software (Software, metaphor and Conway's Law)

Nat Pryce

I will explore the use of metaphors in software development. We often use deliberate figurative metaphor to introduce novel designs. I will relate this creative aspect of metaphor to cognitive metaphors that have been investigated by George Lakoff et al. Lakoff's research posits that the only way we can think and communicate about abstract concepts is to relate them, by metaphor, to our physical environment. And you don't get much more abstract than software! We usually do not even notice the metaphors we are using when describing software. However, careless use of metaphor can hinder the process of designing software, communicating about software design and organising ourselves to collaborate on software development. If we cannot avoid metaphor we must use it to our advantage and avoid its pitfalls.

The Novoda Craftsmanship University

Paul Blundell

The journey of a craftsperson is difficult and never-ending, full of hard work, sweat, and tears but it is also a journey of joy, discovery, knowledge acquisition, and professional growth. We’ve created Novoda Craftsmanship University (NCU) so that employee's can take this journey together. In this talk Paul Blundell will show how you can apply principles of craftsmanship to complex & iterative mobile Android & iOS products and how mobile craftspeople develop together and share knowledge at Novoda.

TDD, as if you meant it

Alex Bolboaca

One of the difficulties of developers starting to apply Test Driven Development (TDD) is letting go of preconceived notions of design and allowing themselves to evolve it. I have successfully used TDD As If You Meant It as a way of showcasing how design grows when doing TDD. TDD As If You Meant It is a set of constraints created by Keith Braithwaite that forces developers to let go of their set blueprints and allow the design to evolve. I've noticed in code retreats and dojos that the technique is very difficult to get right. In this session, I will explain how to start correctly, how to apply all the rules and how it shows the evolution of software design.

Get Kata

Kevlin Henney

Coding katas are a way that programmers can kick the tires of their programming languages, paradigms and practices. Typically anchored in a TDD cycle, katas are typically simple problems that give programmers the opportunity to exercise deliberate practice and explore different approaches, whether programming style, pair programming or test-first programming. But the simplicity can be deceptive, with many programmers tiring of these katas too soon, missing out on some of the more mind-bending and paradigm-expanding opportunities on offer. This session will pick on a couple of katas and dig deeper into TDD, lambdas, language(s), (dys)functional programming and Alcubierre drive.

Usable Software Design

Johan Martinsson

Did you ever think of the user of your code? Not the one using the application, but the developer that has to change the code after you. Does that person have a good tool for the job, i.e. is the code usable? What can we learn from other domains like ergonomics, usability and in general design of objects, where the user has been in the center of the design process for decades? Well first of all it tells us what are the weaknesses of all designers, even the greatest and how to remedy that. Secondly you'll learn why "It's not the users fault, it's the designs fault" and how to remove sources of bugs using BugsZero design. You'll get a fresh new perspective on Clean Code, difficulties in TDD and what's the power of DDD. Last but not the least, you'll discover how "Usable Software Design" naturally gets a lot of traction where TDD and Clean Code meet resistance.

WebOps for the Overloaded Developer

Samir Talwar

At lightning speed, this talk will cover the bits that aren’t code that make up a working web app. These include servers, monitoring, deployment mechanisms, logging, alerting, secret management, recovery mechanisms… you get the idea. Material will be provided afterwards so you can try everything out on your own and really cement the concepts for yourself. Topics include: How to set up a web server on Linux, deploying changes to a web server with minimum downtime, keeping an eye on your server to make sure things are working, tracking down production bugs, and secure communication over HTTPS.

Confessions of a developer community builder

John Stevenson

A community starts by finding another person who shares the same interest and when found this greatly increases your learning potential as a developer. Communities can be formed inside your company or across the wider developer community, in person or online.
But how do you do that and how do you encourage more people to get involved? And how do you maintain a welcoming community which people want to remain part of? Just how big is a community anyway, is it 3 people or 3 million?
I'll share my community building experiences from a diverse set of developer events; from brown bags, meetups, mentoring, dojo's, workshops, hackdays and conferences. These experiences range from the happy to sad, exhilarating to exhausting and many very nervous moments in between.
By the end you should have lots of ideas and more confidence in starting and growing your own communities, appreciating how you can build a community without a huge amount of effort.

Understanding Understandability

Michael Feathers

Believe it or not there was a time when many people in the industry felt that OO was too hard for the average programmer. Yet here we are taking an industry plunge into functional programming and tooling that would’ve tested the limits of what people could tolerate just ten years ago. We underestimate ourselves and we do it over and over again because we conflate cultural understandability with cognitive understandability. In this talk, Michael Feathers will talk about what we know about computational understanding and where we might end up if we accept that it changes over time.

Go-ing there and back again

Steve Freeman

This talk is another reminder that tests are code too and need care and feeding. It describes an experimental spike that we ran on a complex Go project to make the integration tests faster and more readable. We showed how not to rely too heavily on the testing framework and to refactor test code to represent the domain better. We also showed that teams have to move at their own pace, and that teams have to take into account the “House Style” of coding.

Co-authored with Winna Bridgewater, software engineer at Pivotal

The day after tomorrow: Let the machine do the coding

Nicole Rauch and Michael Sperber

Programming means suffering - today. The programmer needs to do the typing herself (except for the trivial code snippets that Eclipse can bang out), the machine's job is to nag and reject when there's an error. In particular, a modern type system can be very good at pointing out errors, but the human still needs to tinker with the program to make it shut up. This is in spite of the fact that most of the domain knowledge is already contained in the type definitions and method signatures: Program by Design shows how this can work. Now, if we specify a little bit more, shouldn't the computer be able to write the code? The future of programming or just pipe dream? A new generation of programming languages and IDEs gradually turns this dream into reality: These tools are slowly becoming partners in software development. They make programming more fun, and can cut down dramatically on the error count. In the process, they liberate developers from implementing recurring patterns over and over. Developers can focus on the individual aspects of the software, on properly modelling the domain and on the user experience.

Craft Thinking

Mashooq Badar

We choose to think of Software Development as a Craft. Usually when we associate Software Craftsmanship with Code Quality and Agile (more specifically XP practices). That is a very narrow view. In fact Craftsmanship is about our innate desire to do a good job - there is a craftsman or craftswoman in all of us. This leads me to the question, what is the general philosophy behind craftsmanship and what does it mean specifically to software developers? In his book, The Craftsman, Richard Sennet takes a philosophical view of craftsmanship through the ages in order to understand what happens when people try to do a good job. I will attempt to relate this view to Software Craftsmanship in particular. There are many lessons to glean from studying the history and philosophy of craftsmanship to answer the many questions that are relevant to our craft. For example; the struggle between practical and perfect, how do we achieve the right balance, the concept of "fractured skill" where we become only specialised in only a subset of the skills necessary to create the whole, the role of failure in learning, choosing the right tools and skills to learn? I will try to wet you appetite for exploring craftsmanship from a different perspective so that we can better understand Software Craftsmanship.

The importance of syntax in clean code

Hadi Hariri

We speak about clean code so often, focusing on things such as Single Responsibility Principle, Separation of Concerns, and all the other TLA's we can think of. We talk about clean code in both Object Orientation and Functional paradigms. We show examples of clean code in a variety of programming languages, and we say it doesn't matter what language you use, clean code is essential. But the truth of the matter is, language plays a bigger role in clean code than we might think, if by clean we understand code that is concise, comprehensible, readable and does not have a lot in the ways of redundancy and noise. In this talk, we're going to look at the case for Kotlin, a language that in appearance is very similar to Java and C#, and only adds what some consider a few dashes of "syntactic sugar" here and there. We'll see whether combining these small nuggets, it adds value to what we could consider more concise, readable, and consequently maintainable code.

Learning, Communication, Quality, and Craftsmanship

Joe Schmetzer

Culture is difficult to describe, but it has a huge impact on the successful adoption of new techniques. What cultural factors allow successful change? This talk explores growth mindset, mutual learning, communication patterns, and quality focus as enablers to the adoption of craftsmanship.

Closing Keynote

Rachel Davies

An ending is an opportunity for a new beginning. As we bring SC2017 to a close, you’ll have picked up new tools and techniques that you’re keen to try out and connections you want to explore. How will you get value from our time together and share that value with others? In her closing keynote, Rachel will inspire you to pause, evaluate, and begin afresh