@DDDEU 2018: My personal Day 1 summary (+ Intro)

Some years ago I found out / was feeling, that software development was lacking of business focus. On several teams I managed, worked with, multiple solutions were given without really understanding the problem, domain, business needs. Sometimes even worst, shifting more focus on tech details than delivering real value. I really saw the difference between teams, that discover and work closer to business colleagues, than other ones that were expecting pieces of paper with requirements, having rare or infrequent interactions. The best performing teams I have ever seen, are the ones that have in one team, all possible skills to bring the product to the next level, including it, marketing, product profiles,…, working as one team. focused on delivering value. ( Here, you can find, my first and unique conference talk about this thoughts). On addition, having worked on different sources codes, database structures, the symptoms were more or less the same. The business domain was not really identified on the code, mixing infrastructure, business, together, using different naming conventions that the ones used by business experts and the real processes where hard to follow

All this insights, vision about software, business and teams was based on my personal evolution, from architectural/dev mindset, to a more overall Business/Tech balanced mindset this last 5–6 years. (Perhaps I will always be tech minded, and an always learning dev :) with the wish of reaching the craftman skills)

Based on these learnings, I started seeking for new ways of tackling the business needs, team product ownership, trying to:

• Focus software developers, tech teams, on developing products, features , having a deep business knowledge,
• Find better ways to interact with other departments to define the real needs
• Having a shared understanding, about what we are doing, is needed and what we are building

On the way I found several things, Hexagonal Architecture, Lean Startup mindset, User Story Mapping…

Finally I reached DDD (3 years ago). I started reading several books, coursed Vaughn Vernon IDDD Workshop, and the deeper I came In, the more I was interested on. I noticed there was a conference, DDDEU 2017, and I said “I must go”

The conference really was a mind change for me. I was expecting a more tactical approach, as a usual tech minded person, and I found a really more strategical approach. That was mind blowing, It took me several days to really figure out what is DDD about ( as it is for me)

DDD means for me, tools, techniques to discover on a collaborative way the business needs, problems, finding a shared vision, that enables modeling a solution that delivers value. I was focusing too much on the tactical part, searching recipes, without really understanding, that strategic approach comes first, to enable tactical.

DDD is more philosophical mindset than a tech approach. You can use only the strategic approach and It will be a plus/valuable, having discovered the domains, context and then using afterwards your personal heuristics without the tactical modeling approach.

After this learnings, I read more and more, discovered and implemented several models, feeling more comfortable about the DDD mindset

[Sorry for the intro, but I think it makes sense to have the right context about my wishes and learnings]

With this baseline, this years DDDEurope expectations, were the following:

• Learn from other person’s experiences
• Find ways to empower teams on DDD
• Find new ways of looking at domain models
• Discover some new techniques
• Empower my previous learnings

Let’s start with the summary :)

(It’s important to highlight that my summary are mainly, highlights and phrases about the

Day 1 Summary

Without expecting to ….1 year after my first DDDEU conference , I was sitting almost on the same seat, at the red room of the Meervaart Theater, waiting for the opening keynote.

KeyNote: Profesor Dave Snowden

He started talking about how we see the world, and some definitions:

sensemaking vs sense making, topologies vs taxonomies, and models, maps & frameworks

• “The language you speak defines how to you see the world”
• “Models seems to represent the world”
• “A map shows you where you are”
• “Frameworks help you to see thing from different perspectives”
• “Scaffolding is not intended to be permanent”

After this introduction, he started talking about modeling, and “that there are no recipes”. “We need more chefs that recipes followers, for modeling and software engineering”. “We only see what we are attracted/expect to see, based on our heuristics”. He introduced a new word for me, called Exaptation, and after he went through Serendipity, “on experiments, discovering, we don’t find what we are looking for but we discover other cool things on the path”. Another sentence I liked was “ Software architecture is about unarticled items”

Having described the process of discovering , modelling and learning, he connected the dots, introducing systems, its behaviour, and the cynefin framework. He made a funny description about getting around the company’s expense reimbursement system. He summarized the example with “If you overconstraint a system, people work around it”.

Going deeper into the cynefin framework he started to explain system analysis approach:

• Chaotic Systems, have no constraints, work randomly
• To go into complex systems, it’s important build boundaries, make experiment and see cause effects patterns. Sometimes what worked at some time might not work today. context matters
• We need to apply a coherent approach on modeling, to understand the system, interacting with different part of the system. Only modeling, architecting will not show you reality
• We need to make sense of the work in order to act in it

He mentioned Liminal thinking and delay decisions until we have enough information.

And reaching the end, he focused on people interaction, and finding shared vision about the model. The key is to focus as much time as possible on discovery, trying to discover continuously. Talking to each other, brings you to a common view, because everybody thinks about the same thing different, without context and discussion. Dispositional thinkers, are key to find new roots and ways to look at the model.

I must say, that this talk was one of the most inspiring of the conference.

Here is good sketchnote about the talk

Domain Language throughout Testting, Combining BDD & TDD via Kenny_baas

Kenny shared, how he arrived on a source code where it was impossible to know what is the code about, which were the business processes. He had a “shitty code”, and he described how he went over it. He found the key via BDD and TDD; making meaningful tests. A summarized the talk with the following notes:

• Software development is about learning coding is a side effect
• Learning = Failing (Blackbox thinking)
• TDD+ BDD = Empathy Science Feedback
• Property Based Testing is an awesome tool
• Feature Mapping + Example mapping can help you to frame domains
• Serenity tool is BDD with steroids

I expected more from the talk, having more insights, perhaps Kenny did a great work. That is part of expectation management :)

From Legacy Chaos to the promise land of DDD via @EllenLippe and @AnitaKvamme

I think the best talks, are the ones that share personal experiences, and this is one of this kind.

They explained their trip from a legacy app, to a new DDD based application, focusing on the main pillar, people. Part of the team had some knowledge on DDD. The team had different type of persons, where learning and discovering, had different process for every one. Finding a common way, was key. On the why to DDD, they noticed that colleagues with soft skills, where the ones to got the meaning , dynamics earlier. “DDD is a mindset that will form your code”. With team sessions, discovering domains together, pair programming, feature tests, and defining the right bounded context, where the pillars to reach the promiseland. Focusing on bounded contexts, gave them a safety net, on applying changes

Testing was key, learning that focusing on features, not overtesting the application, testing “only” at the top of the bounded context, mocking at the repository and anticorruption layer, was the right balance, and best value output. With this strategy , being focused on feature, making less mocking and crazy refactoring, due useless tests, the team were able to avoid 2 weeks of production testing per release.

Bounded Context + feature tests = Freedom Power

“Introducing feature toggles, keeping temporarily the legacy app parts, gave us an added safety net”. I really liked the example of sending the commands to the new and old app, and comparing database results, to really check if the new app was performing well. (Example = Complex calculations)

“Feature toggles, worked for us , to tackle the giants, step by step, deliver frequent, continuous learning..”

“Legacy is gold, giving us automatic comparison (helping us to discover requirements), and support to define bounded contexts, apart from key knowledge to build the new world with DDD”

As summary , the following concepts where mentioned:

• “Old habits die hard”
• “ The solution doesn’t have to be perfect. It’s still good and much better than before”
• “It starts and ends with the team. When you know each other, and have a shared vision, you will be able to code better”

By far , the best talk i attended on the conference

On the talk, this article of Julie Lerman was mentioned, as a good guideline, moving from a data centric approach to a domain based one.

(DI|Con)vergent Mob Refactoring Workshop

Very nice workshop, focusing on the benefits of mob programming, I’ve read a lot about it, had some insights from some colleagues but never went with a real well defined practice.

We build teams of 4, trying to have diversity of people , skills.

We started the opposite way (as the one is promoted by mob programming), driver is the only allowed to talk, and others can talk if driver raises question. Requirements where given, and we need to implement them. Once finished one requirement. we could request another assignment.

It was a total mess. We changed the driver every 10 minutes, and depending on the driver, there was more or less collaboration, based on how confident he was on the solution. There was no shared vision, some people were dissapointed, and wanted to talk, bout couldn’t

The second part, was build to go in the right way, driver only writes, what the other say. Shared understanding, arguing, whiteboard and consensus were key to guide the driver.

With the guided process of being first divergent and then convergent, main benefits of mob programming where really highlighted

KeyNote: Eric Evans

I felt that Dave snowden talk and eric’s ones where somehow linked. Evans went again through the JodaTime library as last year, exploring other ways of looking at models

“Doing software is breaking out the box”. Supple design is key

“Generic subdomains make good practice grounds”. I really believe that there are a bunch of generic domains, that we can use as key on hand solution.

“Sometimes excluding the central concept, is a good exercise”. Model exploration whirlpool was mentioned

Making yourself some questions can help .” Is the model useful for the problem?. Is it productive?”

“It is important to research, to find a fit to a part of your problem”

If i would choose a summary phrase of the talk it would be “Legacy blindness. We get so used to it, that we cannot see forward…especially when legacy is good”

Eric is always inspiring, and makes you believe that there is always something that you missed out, or you need to focus more on. Different perspectives, ways of looking at the model, is a must to solve modeling challenges.

That’s my personal Day I summary. :).

Thanks