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.
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.
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!
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
Michael Feathers
Closing keynote of SC London 2019 from Michael M. Feathers, author of Working with Legacy Code.