Keeping It Simple
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? When we say ‘simple’, is one person’s ‘simple’ necessarily the same as another person’s ‘simple’? And, of course, if simplicity is so important, how do we simplify?
In this 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 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 more complicated and 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. 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.
As well as presenting concepts, examining themes and considering code, this masterclass will also offer plenty of opportunity for questions and discussion, plus some hands-on refactoring exercises (options will be available in different programming languages).
Topic summary
- What kinds of complexity do we find in software systems?
- What are the costs of accidental complexity in code and architecture?
- Where does complexity appear in our organisations and processes?
- The technical debt consequences of long-term technical neglect
- Why and how details matter
- Refactoring as an act of simplification, discovery and evolution
- Examples and consequences of refactoring
- Kinds of refactoring resistance
- The role of testing in keeping code, architecture, delivery and life simple
- How to be the human in the loop when working with AI code generation
- Programming paradigms and their effect on complexity
- Declarative programming versus imperative programming
- Keeping code, architecture and development process lean
- Practices for getting started
Kevlin is an independent consultant, trainer, speaker and writer. His development interests and work with companies covers programming, practice and people. He is a contributor to the Modern Software Engineering YouTube channel. Kevlin is also co-author of two volumes in the Pattern-Oriented Software Architecture series, editor of 97 Things Every Programmer Should Know, co-editor of 97 Things Every Java Programmer Should Know and former columnist for a number of magazines and sites.