Talk Videos

2019 | 2018 | 2017
Day 1 Talks
Opening Session - Aligning Product and Software Design

Sandro Mancuso

In this talk, Sandro will be presenting a few techniques and a far more collaborative way of working, aligning product and software design.

The collaboration between business and technology while building digital products is still not as close as it should be.

There is a lot of work that goes into the strategic evolution of a product that is not visible to technology. Product design is often created without much input from technology, resulting in unreasonable expectations. There is also a lot of effort that goes into software design and architecture that is not understood by the business. Developers complain that business do not have interest in software design. But what often happens is that developers struggle to demonstrate the value of software architecture and design and how it can impact the product strategy. This lack of close collaboration and common understanding that product and software design mutually impact each other leads to badly designed systems that constrain business evolution.

Session 1 - BDD in Action: Testing Modern Web Applications at Scale

John Smart

In this live-coding session, John will demonstrate how software engineering design principles and practices can be applied to modern test automation. He will automated a number of realistic BDD scenarios against a real-world application, using both UI and REST-API automation, and showing how the powerful Screenplay pattern can be used to make your automated acceptance tests cleaner, more scalable and more reusable.

Key technologies used: Java, Cucumber, Serenity BDD, the Screenplay Pattern, WebDriver and RestAssured.

Session 2 - The Lost Art of Software Design

Simon Brown

"Big design up front is dumb. Doing no design up front is even dumber." This quote epitomises what I've seen during our journey from "big design up front" in the 20th century, to "emergent design" and "evolutionary architecture" in the 21st. In their desire to become "agile", many teams seem to have abandoned architectural thinking, up front design, documentation, diagramming, and modelling. In many cases this is a knee-jerk reaction to the heavy bloated processes of times past, and in others it's a misinterpretation and misapplication of the agile manifesto. As a result, many of the software design activities I witness these days are very high-level and superficial in nature. The resulting output, typically an ad hoc sketch on a whiteboard, is usually ambiguous and open to interpretation, leading to a situation where the underlying solution can't be assessed or reviewed. If you're willing to consider that up front design is about creating a sufficient starting point, rather than creating a perfect end-state, you soon realise that a large amount of the costly rework and "refactoring" seen on many software development teams can be avoided. Join me for a discussion of the lost art of software design, and how we can reintroduce it.

Session 3 - What does GREAT Architecture Look like?

James Birnie

When we talk about architecture in software, what does it mean? If you ask 10 technology professionals "what is architecture?", you get about 15 different answers.

Sometimes an organisation (usually one crippled by legacy software, legacy business structure, legacy methodologies and legacy culture) has a role called "enterprise architect". This role is almost always counter productive. Instead of planning how to deliver value through new software and structures the prevailing culture forces this role to perpetuate the legacy in all of its forms. At best this places constraints on teams by telling them how to use existing systems to extract new value. At worst this culture actively obstructs new value by only telling delivery teams what they CAN'T do.

So how should we view architecture and architects? How should we understand, and measure, our architecture and how can we make sure that our architects both add value and help value to be added? In this talk I'll explain how modern architecture and architects should work, based on our experience of helping complex organisations to move away from their legacy culture and systems.

Session 4 - The Gordian Knot

Alberto Brandolini

Some companies are going “full DevOps” and apparently releasing at the speed of light. Other companies are still struggling with estimations and slowly thinking about going microservices. Others are happy with their monolith, but struggling with recruiting.

We’re all developers, but we’re not doing the same job. The line connecting a problem to its solution is relatively straight in some organizations and incredibly convoluted in others. Processes, software architectures and organizations are not separate concerns, neither are they orthogonal. Pretending to fix one thing without touching others is a losing battle.

We’re part of the problem. Our software is part of the problem. We can be part of the solution too.

Session 5 - Testing Microservices: From Development to Production

Daniel Bryant

Dividing a system into a series of services that communicate over an unreliable network naturally creates challenging conditions for testing inter-service interactions. Each service has its own functional requirements, and performance and fault-tolerance characteristics that need to be validated during development, the QA process, and continually in production. Join Daniel Bryant to learn about the theory, techniques, and practices that can help to overcome these challenges.

Overview and learning Outcomes:

  • • Introduction to the challenges of testing distributed microservice systems
  • • Learn tactics for isolating tests within a complex microservice ecosystem
  • • Join a whistle-stop tour of consumer-driven contract testing and API simulation
  • • Understand where to implement fault-injection within doubles in order to validate nonfunctional requirements in development and QA
  • • Understand the benefits of continually validating microservice systems running in production

Session 6 - Reading Code Is Harder Than Writing It

Trisha Gee

It's funny that computer languages are the only languages where one learns to write before learning to read. It's actually not uncommon for people to never really learn to read code. This seems a little unbalanced given that we actually read code much more frequently than we write it.

Even those who promote software as a craft sometimes fall into the trap of often talking about writing clean code that people can read, yet not placing much emphasis on the skill of reading the code.

Yet the ability to read code must also be a skill, and as such it must be something that can be learnt and practiced. In this presentation, we're going to look at:

  • • The different reasons we might have to read code, and how that should impact us
  • • The problems we face when reading code (even our own!)
  • • Tips to bear in mind when we're reading code
  • • Tools we can use to help our understanding
  • • How and where to practice these skills

Panel Discussion

Simon Brown, Sandro Mancuso, Alberto Brandolini, Trisha Gee

Architecture in an Agile Environment

Day 2 Talks
Session 1 - Feedback Loops for Software Delivery

Gojko Adzic

Feedback loops are everywhere in software craftsmanship, from instant micro-feedback loops such as code linting to large-scale cross-organisational loops such as incident post-mortems and product milestone planning. Developing software heavily relies on effective feedback loops, but very few teams approach feedback systematically. With complex interdependent adaptive teams and organisations, feedback systems can be counterintuitive and confusing. Gojko will explain the science behind feedback and help you set up and benefit from feedback loops much more effectively, on all possible feedback levels.

Session 2 - TDD with Petri Nets

Aslak Hellesoy

A Petri net is a formal mathematical modelling language for distributed systems, a bit like an advanced state machine. Petri nets can be used to model business processes as well as lower level communication protocols.

Unfortunately the agile community has largely eschewed formal specification tools and languages because they've been associated with big, up-front design.

This is a misconception, and in this talk I will demonstrate how Petri nets can be used to define a distributed process, and how the model and the code can evolve incrementally with TDD.

I will also demonstrate how a Petri net can be used as living documentation and executable specification. No cucumbers required.

Session 3 - What's Machine Learning Got to Do with It?

Frances Buontempo

I'll talk about Craftsmanship and Machine Learning, in particular testing/fitness, iteration and feed back. Believe it or not, there are some strong similarities in approach between AI/Machine Learning and Code Craftmanship. I will look at this, including:

  • • Does machine learning always involve data? Fran thinks not - it often involves doing something random, which is a bit like mutation testing, property based testing and fuzzers.
  • • AI models often learn from fitness functions, so you need a sense of what counts as success or failure. Is it any good? Can it get better? Sounds like developing code? It does to me.
  • • Many Machine Learning or AI approaches start somewhere, maybe with something random and iterate - they usually have a for loop at their heart. Each iteration attempts to improve, either getting a better fitness score or winning mores games or similar. Again, this is how we develop code. Try. Test. Tinker. Rinse and repeat.

I believe the essence of both is feedback. I'll delve a little into some history of AI and modelling, showing how and why feedback is important there and what craftspeople can learn from the AI community. The AI community have a lot to learn from people who take time and care to code well, but that's another talk for another day.

I'll leave us with a few questions/ideas to ponder

  • • Will AI replace programmers? See how Fran generated code for FizzBuzz (and weep). This uses genetic programming to generate a syntax tree for a language. It extends genetic algorithms, so means I will give a very short overview of how both work.
  • • How to use data on your code base/bug reports to predict what might go wrong next, possibly mentioning something around "Your code as a Crime Scene" (Adam Tornhill's book) in passing.

Session 4 - Balancing Forces in Software Design

Mashooq Badar

According to Christopher Alexander - 1974, "Design is often about achieving a balance between conflicting forces", the same is true for Software Design. I will explore a few of these "conflicting forces" that we aim to balance when designing software.

Panel Discussion

Gojko Adzic, Mash Badar, Rachel Davies, Michael Feathers, Seb Rose

Bridging the Gap Between Business and Technology

Session 5 - Microservices: Sharing Is Caring

Rachel Davies

Maintaining shared micro-services is a pragmatic approach to building resilient products.

At Tes, we have a dozen teams building products that use common shared micro-services for basic services, such as sending emails and authentication/authorization. Although the idea sounds simple, in practice sharing code between teams can be challenging. Shared services risk becoming polluted with product-specific details or turning into no-go areas that engineers fear to change. Come to this talk to hear about how we overcome these challenges at Tes and hear our tips for how to maintain a healthy set of shared micro-services.

Session 6 - Software Contracts Or: How I Learned to Stop Worrying and Love Releasing

Seb Rose

The test automation pyramid suggests that we should favour unit and integration tests over end-to-end tests, which leads developers to use test doubles (fakes, stubs, mocks etc.). The risk is that the developer's test double does not behave in exactly the same way as the actual component that it is replacing. When this happens, the tests all pass in your build pipeline, but you get failures when it's released into an integration (or production) environment.

Contract testing is a technique that can give you confidence that your test doubles are accurately simulating the dependencies that they replace. This is not a new technique, but the extra investment in creating and maintaining (yet another) suite of tests has restricted its uptake. Instead, organizations mitigate the risks by investing in more and more integration environments and end-to-end tests. This was always expensive, but with the adoption of micro-service architectures across the industry, the cost and complexity has escalated to a point where this approach is no longer sustainable.

There is now an urgent need for organizations to revisit contract testing, with a specific focus on consumer driven contracts for micro-services. In this session, you'll learn why contract testing is critically important and get an overview of how you can incorporate contract testing in your development practices.

Closing Session - Socio-Technical Practice as Craft

Michael Feathers

Last year we were privileged to hear Michael’s insights into "Working The Way That We Want To - An Imagined Future". This year he’ll be addressing Socio-Technical Practice as Craft in a talk which promises to close our conference with a bang!

Organised by Codurance | All Rights Reserved © 2021