Training on detecting accidental complexity

Accidental complexity is a huge topic in our industry and it is often cited as a reason for slow development or even failing projects. However the term accidental complexity is a term that is often used, but not very often understood - at least in my humble opinion. Also accidental complexity is often discovered when it is too late and the project is already on a bad track.

So what i present here is a fun exercise, that gives software engineers an opportunity to discover accidental complexity and become more sensitive about it. Reducing accidental complexity is not a topic of this exercise, but the assumption is that when you realize accidental complexity earlier (because you are more sensitive about it) it is easier to get rid of it or even avoid it.

This exercise can be done alone or with a group of developers - and let me assure you it is tremendous fun when done with a group.

The idea

This whole endeavor started with me watching a talk by the great Kevlin Henney ( Small Is Beautiful ). Where he makes some remarks on FIzzBuzzEnterpise . I got curious and started digging into the repository of FizzBuzzEnterprise. And i have to admit: I felt at home immediately. i've done most of the things i could spot in that code base. And i had a lot of fun reading this code.

Now FizzBuzzEnterprise is not a very serious project. It actually a self proclaimed project of satire, a project which displays our/my bad habits in an exaggerated way so those bad habits become obvious. And they have done a great job - kudos to the enthusiastic engineers of FizzBuzzEnterprise.

Of course this made me wonder about my habits and what i would do differently - it's always good to do that and sometimes you just need the right nudge to do this. And then it hit me, that this experience could be reproduced to provide this little nudge to get you thinking. And i started creating this training based on FizzBuzzEnterprise.

The theory

Just giving a group of engineers just the code of FizzBuzzEnterprise might already be a worthwhile experience, but i decided to add some extra cheese to set the context and get them into the right mind set.

So the whole thing starts with a little easy to grasp definition of complexity - all the details that are part of your software - and accidental complexity - all the detail that are part of your software, but not necessary. Note that i am not referring to the theoretical computer science terminology of complexity here. This is something completely different and should not be mixed with the topic of this training.

While my shorthand definition is sufficient for this exercise i remembered that we have a huge problem in our industry: Naming things! So i started to do some digging in the literature on alternate meanings of accidental complexity and i was not disappointed - i am easily fascinated by such ambiguities.

The first notion of different kinds of complexity came from McCabe in 1976. In his paper "A Complexity Measure" he introduces a graph based measure that basically describes how simple code could be if it would not be spaghetti code. Since most of use have left the days of spaghetti behind them, this metric is not very important anymore, however the related cyclomatic complexity is still widely used and regarded as a useful metric of code quality.

In 1986 Frederick P. Brooks published his famous paper "No Silver Bullet — Essence and Accident in Software Engineering" in which he first coins the terms essential and accidental complexity in the domain of software engineering. His definition goes back to Aristotle discussions on essence and accident - so basically we now enter the field of applied philosophy. By this definition the essence of software would be the business logic of the software - the reason and value of the software - while every other detail -like programing language, build, architecture, ... - is the accident - still necessary but we only use it to serve the essence. And he concludes that every software has an essential part and an accidential part and one should wonder what part of software is truly essential and what is accidental..

Besides this very philosophical definition one often encounters also another more literal meaning, as in complexity by accident. Well meant code that ended up being more complex than intended due to decisions taken along the way - in short complexity that is not necessary. Decisions like: "We should use pattern XYZ to increase maintainability/testability." Or: "We should optimize for memory/processor/network usage". Each of these decision can cause additional complexity and each of these decision can be right, but when they are not out pay the complexity they add it becomes an accident. Sadly i could not find literature using this meaning (it's out there for sure - so if you find it please send me a link). This last definition will be the base of the following exercise.

The fun

All participants split into smaller groups and start diving into the code. Their task: Find accidental complexity and try to explain why it is accidental. And it is not hard to find such complexity in FizzBuzzEnterprise. However trying to explain why this is not as it should be is harder. Especially when you realize that some of the complexity that you would deem accidental is actually necessary to keep another source of complexity at bay.

After a 30 minute dive all groups meet again and present their findings. This alone is already much fun, but i then take the role of the advocatus diavoli and try to defend the complexity with well known terms of our industry - being open for new features (whatever that might be in FizzBuzz), separating responsibilities, ...

These discussion can be very lively and enjoyable. I let them run wild and was very happy about it, because people have different approaches to understanding software and such a discussion is a great opportunity to learn from each other.

Conclusion

All code that is never executed is meaningless. Same goes for other projects like this exercise. So i performed it twice up until now - once with the Softwerkskammer Lübeck (a very friendly and smart bunch of software experts) and once with a number of engineers in the company i work at - we have a monthly thing for such endeavors where anyone can present.

There are other ways to get people to think about accidental complexity - like a fuckup-night where everybody presents his worst piece of code. I believe this exercise is another useful tool to engage software engineers into reflecting on their practice and hidden complexities in their code.

I don't have any data on how more sensitive participants have become to accidental complexity due to this training - on the other hand i am also not sure how one would measure this. Nevertheless the testimonies after the training were very positive and stated that participants are likely to reflect more on their code with this focus on accidental complexity. And my sincere hope is that this reflection happens and that it helps to avoid accidental complexity in an already complex world.

Usage

If you thought this is something you want to try. Feel free to do so. You can get my minimalist slides at gitlab.com/LuebeckoTalks/accidential-comple...

It would be nice if you acknowledge me when doing this exercise and let me know how the exercise was received.