We are often urged to keep code, design and architecture simple. What, however, is the motivation for this? And what does this mean in practice? Is simplicity just an aesthetic or does it also have social, economic and technical implications? Does simplicity reduce cost of change, of maintenance, of ownership? And when we say ‘simple’, is one person’s ‘simple’ necessarily the same as another person’s ‘simple’?

In this masterclass…

• We’ll consider simplicity from a number of viewpoints, including essential versus accidental complexity, value demand versus failure demand, simple versus simplistic.

• We’ll also look at typical sources of complexity in our coding habits, along with code examples in various languages.

• We'll see that many practices and approaches can be used both to simplify and to complicate. It's all in knowing how and when versus how not to and when not to use them. For example, we can encourage reuse through code libraries, platforms and services, but we can also make an architecture needlessly complex and draw in unnecessary dependencies, with implications for maintainability and security. Similarly, AI assistance can be employed to make code simpler and easier to work with but, without attention and guidance, it can make things harder in the long run, becoming a new source of legacy.

• We’ll explore verbose and convoluted code, the effect of programming paradigm and how we can turn down the imperative noise of many languages and styles with declarative techniques.

• We'll learn it’s not just in our programming and languages where we find complexity: our development processes, tools, architectures and organisational cultures can often encourage unnecessary complexity, costing us time, effort and opportunity where simplicity would have had the opposite effect.

• We’ll look at how we can work with incomplete knowledge without adding speculative complexity of so-called future proofing.

• We’ll acknowledge technical debt and neglect for what they are and understand why ‘legacy’ is so often the opposite of ‘simple’, no matter what its backstory. We want to make sure that as well as recognising unnecessary complexity in the small and the large, that we also have an idea of the practices that can help with simplification.

As well as presenting concepts, examining themes and considering code, this masterclass will also offer plenty of opportunity for questions and discussion.

Speakers interview each other on topics that matter to them.

The Program Committee brings special guests in front of the camera — with you as the audience. Some interviews will be planned, others completely spontaneous. All of them will be magnificent, no doubt about it.

Expect the unexpected.

The future is not what it used to be. From the end of the 19th century, through the dawn of the Atomic Age and past the rush of the Space Race, the future was painted as a place of possibility and optimism. But now? Not so much. Our view of the future lies somewhere between neutral and gloomy. Why the change? That question has come up almost every time our Program Committee has met. Back in the good all days the future was always bright. Innovation and craftsmanship was blooming. Failure not a topic.

So, if the future is not what it used to be, what is it? In this keynote, PC members Kevlin Henney and James Lewis will look at the future seen through the eyes of the past.

Software is executable fiction. Software development is about constructing narratives, drawing from a broad palette of paradigms and technologies, married to our understanding of the needs and wants for a system. Abstraction allows us to simplify and reify the complexity of the world into a formal description that we continually update. Abstraction allows us to ignore things about the world and about computer systems that are irrelevant or inconvenient.

But there are limits to the enchantment of code and our ability to maintain illusions. When the rubber hits the road and the packet hits the network we find universal limits are there to keep it real. Nothing can be instantaneous or infinite. Not all computations can be reversed. Not everything is computable. Not everything can be known. Every computation costs time and energy.

Accompanied by a bunch of SF and retro pop culture references (not just Star Trek — we'll be crossing the streams), let's explore the metaphors and realities of the physical world and how they play out in our software systems