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 it just an aesthetic or does simplicity 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’ the same as another person’s ‘simple’?
In this masterclass, we’ll consider simplicity from a number of viewpoints, including accidental versus essential simplicity, 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 explore noisy code and the effect of programming paradigm. But it’s not just our programming and languages where we see 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, plus a couple of small coding exercises.
These two days are aimed at developers.
