Last week I attended the DDD Europe conference. This was the 2nd edition, and it was held in Amsterdam, where I live. The company where I work, Werkspot, sponsored my ticket, so what else could I wish for?!
Well, actually I could wish for a good conference, and it was! Very experienced developers were speaking there: Vaughn Vernon, Udy Dahan, Nick Tune, Greg Young, Alberto Brandolini, Paul Raynes, the inevitable Eric Evans, and even Melvin Conway which is probably around 80 years old by now!!
I attended twelve talks and this post is about the three talks I found more interesting.
- Consider the Development Feedback Loop – Melvin Conway
- Domain-Driven Organisation Design @ FlixBus – Thomas Ploch
- Good Design is Imperfect Design – Eric Evans
Some of the talks from 2016 are available on their YouTube channel, I suppose at some point they will make some of 2017 available as well.
Consider the Development Feedback Loop
Melvin Conway talked about how cool it would be if we could build software taking advantage about the natural human hand-eye-brain feedback loop and at the same time allowed us to immediately see the result of our changes.
He draws from a potter’s hands on work with clay analogy to exemplify what he means, how he envisions software development in the future, where someone would simply drag and drop “things”, components, on a whiteboard, connect them and immediately see the results in an “always running” application, reflecting what is on the whiteboard.
He relates this paradigm with DDD, in the sense that this software building process would bring the domain experts into the hands-on development process, the domain experts would be the actual application builders, dragging and dropping domain concepts into a whiteboard. The widgets/components available to the software builders would depend on the domain and would be defined by a Domain Specific Language (DSL).
The DSL to be used by the software builders is what would still have to be developed by today’s software developers.
The concept of having domain experts build the software, hands on, is the most interesting part of the talk. However, the coolest part is that Melvin Conway was researching this in the early 1990s! More than that, he actually developed an application that would allow for domain experts to build software by dragging and dropping components onto a whiteboard! He even showed a few videos where the process was exemplified, using the software he developed in the early 1990s, using Smalltalk on a Windows 3.1, running in compatibility mode on a Windows 95, who was running in a VM on his MacBook! Super cool!!
Domain-Driven Organisation Design @ FlixBus
Thomas Ploch talked about his experience in transforming FlixBus from a traditionally organised company into a “Complex Adaptative System”.
Enterprise applications are systems in ever growing complexity and in constant change. Here, DDD comes into play by giving us a set of practices that help us build software that is prepared for change.
Still, despite DDD, when we have a highly complex application with many developers working on it and a constant drive/need to adjust to market requirements, a traditional approach to company organisation is not good enough, it doesn’t adapt fast enough, it doesn’t scale!
In such context, the solution is to transform the organisation into “Complex Adaptative System”. The analogy given is that of a swarm of fish in the ocean.
There is no higher entity directing each of the small fish, if a threat comes close they decide on their own what to do and, as a consequence, the global shape of the swarm is changed, adapted to its ever-changing context. They are self-organized, both in analysing their context, the problems they are faced with, and deciding on the best solution for it. Nevertheless, although they are self-organised, they all have one common driver/directive that makes them work together: they want to survive!
Transforming a rigid organisation into a Complex Adaptative System
To transform an organisation into a Complex Adaptative System, we first need to understand what are the characteristics of such a system and then change the organisation into complying to those characteristics.
Self-organizing
To achieve a self-organising company, giving autonomy to its teams is a key factor. Without it, self-organisation is not possible! However, “with great power comes great responsibility”, and so autonomy in its own might just bring chaos.
As the fish swarm analogy above, the autonomous teams in an enterprise need a simple and common directive to guide them, a common objective. They need common meaning and moral, which translates into a shared vision, which is part of the company culture.
With a shared vision and a global objective in mind, each autonomous team will be able to analyse its context, the problem at hand, and find the appropriate solutions, the team-specific objectives, and eventually also individual-specific objectives.
Those team-specific objectives are part of the team’s OKRs, they are the conceptual solutions to the higher level strategic objectives.
An important concept to note here is that the OKRs, the team goals, are defined by the team itself as a solution, a response to a higher level objective (the external context change with which the team is confronted, just like the external threat that the fish are confronted with). It’s a bottom-up approach to management, as opposed to the traditional top-down directive approach. In a traditional approach both the problem and solution come from the top of the organisation, but in a bottom-up approach the problem comes from the top, but the solution emerges from the bottom of the organisation hierarchy.
Emergent
Organisational, social and technological change is continuous. The top management entities in a company can not predict all changes. Therefore they can not come up with all solutions required by a competitive market, nor the so much desired innovation. Adaptation to this context of continuous change needs to emerge from the small autonomous components of the company
For the autonomous parts (teams) of a Complex Adaptative System (company) to be able to adapt to change, to new problems, to new challenges, there needs to exist space for experimentation. It’s from experimentation that the best solutions and the innovation will emerge.
Providing room for experimentation implies:
- Giving time for the teams to experiment different solutions to problems;
- Acknowledge and accept that some experiments will add nothing to the organisation and product, but some will bring innovation into play, providing the organisation with valuable, and even key, competitive advantages;
- Reflecting the result of experimentation in a global context of the company with minimal friction;
- Giving up central control, replacing it with monitoring.
Non-linear
Being non-linear means that providing the same inputs might result in different outputs.
This seems pretty reasonable as if we have two independent and autonomous teams, composed of different people, with their own knowledge, experience, views and ideas, and we give them the same problem to solve, there is a reasonable chance that they will come up with different solutions, with different time frames, different pros and cons.
All this means that the organisation, as a Complex Adaptative System, loses predictability. The idea is, then, to give up predictability all together, as it hinders autonomy, and replace it with value as a global pattern, by:
- Understanding how the company generates value;
- Apply the Lean Value Streams pattern to the autonomous teams.
Order / Chaos dynamics
Unfortunately, Mr Ploch (the speaker) didn’t dive into this last characteristic of Complex Adaptative Systems. Nevertheless, I did some research, and this is what I came up with…
Some of the concepts that the Chaos Theory brings us are:
-
Order / Disorder
Chaos is not simply “disorder”, it explores the transition between order and disorder, which can occur in unforeseen ways;
-
The butterfly effect
“A butterfly flapping its wings in New Mexico may cause a hurricane in China”. Another way to express this is to say that small changes in initial conditions can lead to drastically different end results;
-
Unpredictability
Since the initial conditions of a complex system are impossible to know in sufficient detail, it is not possible to predict the outcome;
-
Feedback
Feedback will often provoke chaos.
Relating these to software development, I can imagine a context of Autonomous development teams, set us as Lean Value Streams that go all the way from the end-user to the back-end developers.
From an initial state of order, the development team is confronted with a context change coming from one of the tips in the value stream: end-user feedback. The team, therefore, enters a “disorder” state, where it will analyse the end-user feedback, establish the problem to solve, propose solutions and implement one or several solutions, thus adjusting to the context change and returning to a state of order. This process goes on and on continuously, effectively behaving as an autonomous and self-organized Complex Adaptative System.
Making the change happen
For the traditionally organised company to make the shift to a Complex Adaptative System, there is the need to hire “change agents” who join the company for short periods of time, on a regular basis, to provoke localised organisational paradigm shifts, evaluate and further improve the new workflows.
According to Mr Ploch, these change agents can not be the current managers of the company, at least in the case of FlixBus they couldn’t. The current managers already had their hands full with their everyday work, and it was needed people fully focused on making the change happen.
These change agents can be, for example, agile coaches or coding champions that join the teams for short periods of time and help them work in new ways. However, these change agents need to possess a few characteristics:
-
Empathy
They need to be able to be easily accepted in the teams the integrate, for their ideas and practices to be accepted and embraced;
-
Context Change
They need to be focused on changing the current practices of the teams they integrate;
-
Knowledgeable
They need to have knowledge and experience needed to set up the new processes and dynamics, as well as tackle the challenges encountered along the way.
Further reading
At the end of this talk, Mr Ploch gave us some tips on what to research to get further knowledge on these subjects:
- Cynefin framework
- Nested Systems (team dynamics)
- Measuring value in a value stream
Good Design is Imperfect Design
In the closing keynote, Eric Evans talked about how many times we, developers in general, end up getting trapped in the search for perfect design, perfect code, which is not always a good thing because we need to deliver!
He tells us that we should indeed do our best to have a good design, good code, and it can even be our primary goal but it must not be our only goal because that would be losing perspective of the reason we are building the software: the business.
I would also add that, in the end, what is perfection? Perfection does not exist, it is relative, it depends on who is looking and with what eyes… I mean, what I find perfect, a colleague might not find perfect at all. More than that, what I find perfect in one day, I might find not so perfect the next month, or even the next day.
He told us that we should:
- Align bounded contexts with subdomains: When we can!
- Use Conway’s law to our advantage: When we can!
He gave the example of matching the bounded contexts with the sub-domains, and with the organisation. That is the perfect setup.
However, when the company decides to change its business focus, it will reorganise its human resources, the departments, etc. Even the development teams will likely be reorganised to match the new focus, but even if they don’t, at that point the organisation will no longer match with the code structure. The “perfect” setup is no more, but is the application suddenly a failure? I would say its as good as before.
So what should we do then? Should we refactor the whole thing? Well, it is certainly an option, but we should do it when we can (or as we can) because our primary goal is to deliver value.
This talk actually matched with some points Rebecca Wirfs-Brock mentioned in her talk titled “Design Matters “, where she mentioned that we should be pragmatic, as opposed to dogmatic, when following the software design principles that guide us.
This is, however, not a new idea. The emblematic blue book written by Eric Evans in 2003 already mentioned that some parts of the system are more important than others, namely the core domain is the most important part of the system. The most important parts of the system are where we must put our efforts to have a design that is as good as possible. The other sections of the codebase need to be isolated, using some mechanism like an anti-corruption layer, but do not need to be our main focus.
Even years before the blue book was edited, I was already taught that software development is an iterative process, where with each iteration we improve on the previous work. And this is actually in line with principles of Lean and Agile software development that say that we should release small and often to get quick feedback and be able to accurately decide on the next developments or course correct as soon as possible if needed.
@hgraca 