We are often urged to keep code, design and architecture simple. What, however, is the motivation for this? When we say ‘simple’, is one person’s ‘simple’ necessarily the same as another person’s ‘simple’? And what does it mean in practice? Simplicity is more than an aesthetic: it has social, economic and technical implications. Or, put another way, the absence of simplicity will cost you time, people and tokens. Simplicity reduces the cost of change, of maintenance and of ownership.

Of course, if simplicity is so important, how do we simplify? The two traditional approaches are to eliminate it and to contain it. With all the pressures development organisations experience, both from the legacy of the past and the backlog of the future, as well as changes in technology, whether gradual — classic platform migration — or rapid — AI anyone?

In this workshop, we’ll look at typical sources of complexity in our architectures and development processes, from working with incomplete knowledge to trying to future-proof our systems, from deadline pressure to technical neglect. We’ll look at how generative AI presents opportunities both for increasing simplicity, quality and cost effectiveness, and for introducing accidental complexity, driving up failure and increasing the burden of change. Perhaps most importantly, given this fork in the road, we’ll look at what you can do to avoid the pitfalls and take the simpler path.

In this full-day workshop…
• We’ll consider simplicity from a number of viewpoints, including essential versus accidental complexity, value demand versus failure demand, simple versus simplistic.

• 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 more complicated and harder in the long run, becoming a new source of legacy.

• 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. Suffering from heavy Agile™ ceremony? Too much certification and not enough action? That.
• 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 or business value. 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.
• We’ll look at how architecture represents a mental model we inhabit and, therefore, is something we want to cultivate socially and technically. We want to ensure our cognitive debt is small and our system’s debt of intent is managed.