Daniel Brahneborg

May 27, 2024

Mixed feelings after SDD Conf 2024

Last year Mia and I went to SDD Conf, where the workshop on reliability by Jules May resulted in various improvements of my existing code. This year I went alone, admittedly with rather high expectations. The result was, unfortunately, not good.

The first and last day of this conference has full day workshops, where some topic is discussed in detail, with lots of interaction with the participants. On the remaining three days, there are two sessions before lunch and two after, all of them 90 minutes long. There are always eight parallel sessions, both for workshops and regular sessions, so there is often something for everybody. They normally cover both advanced coding techniques, group dynamics, and more.

However, this year there were lots of sessions discussing artificial intelligence. My interest in this is absolutely zero, as the results are of far too low quality. There were also lots of "how to" sessions targeting the DotNet environment, which I do not use. Unfortunately, several of the sessions that seemed to be more general, ended up showing all code examples in C#, and discussing DotNet specific limitations and their workarounds. So, despite having eight sessions to choose from, at least once per day there was nothing I wanted to spend time on.

Lunch and snacks were of course included. However, the food was more strange than tasty, and the coffee was undrinkable. The hotel served Full English Breakfast, so I did not starve anyway.

Overall, there were a couple of good takeaways.

  1. The software industry consumes a lot of energy and thereby contributes a lot to environmental issues. As developers we should do what we can here, writing more effective code, using better image formats, not automatically starting videos which therefore have to be downloaded, etc. The environmental effect is also an argument against the current AI systems, due to their large energy requirements.
  2. Developers spend most of their time reading program code, not writing it. The keyboard is not the bottleneck. Therefore, code should be as easy to understand as possible.
  3. A good way of making code easy to understand is to minimize the number of variables and states in each function. On a more general level, code should be "beautiful", where beauty simply is the lack of exceptions and asymmetries.

The above ties back both to the principles presented by Jules May last year, and concepts such as domain-driven design: Keep the responsibility of each class and method clear, with clean and beautiful code that is obviously correct. So, I got some inspiration to split functions that are too large, and be more vigilant in not mixing abstraction levels.

Will I attend SDD 2025? Well, that depends a lot on what the presentations will cover.