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 session, 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. To keep it real, we’ll also look at some examples of complexity and their simpler counterparts.