Everybody likes options!

9 November 2015 / one.hundred.acorns / 2 Comments

Who doesn’t?

In our day-to-day life, whenever you have to take a decision, you almost always have lots of options. If your goal is to go somewhere, if it’s near from where you are and if it’s sunny outside, you can go for a walk or by bicycle. If it’s rainy, you can pick up your car or take public transportation. If it’s far away, then you’ll have to book a train or a plane. Now your goal becomes booking a ticket and you still have tons of options! You don’t have too much money? Go with low cost companies! You still want to reduce the price? Well, do not put any luggage in the plane’s hold and take only your backpack. Then you can choose the flying class: economy, first, business, … you can choose whether to use your miles or any other loyalty card, choose between different flight schedule, even choose where you want to sit! And it’s almost the same for the train! Everything is up to you!

The same goes when your goal is simply to eat! You’re lazy? Go at the restaurant! What restaurant? You have tons of options: fast food, Asian food, Italian food, … unless you live somewhere where there’s no restaurant at all, then the only options you have stand in your fridge! But when you’re at the restaurant, have a look at the menu: you see all the options?

Whenever you have a goal, something to accomplish, you always think about all the possible ways to reach it. And if for any reason the option you did choose doesn’t work, well, you simply pick up the next one on the list.

We love to have all those options; we love to be able to pick up the one that fits to our need.

So why the hell, don’t we have such options when it comes to software development?

I don’t speak about the way you will implement something, I don’t speak about the technical decisions here. You might have some technical options in mind depending on what needs to be done (unless there’s an enterprise architect in the way…) I Speak about how to reach a business goal.

Worst-case scenario: you only have specifications that tell you what to do. In this nice MS Word document where everything is written in advance, you don’t need to search for options: you won’t find a single one. Just do it like it’s described, the choice have already been made. Even if you’d like to do something else, you cannot, simply because you don’t know the business goal to reach and what are the measurements to check to know if you succeed. Just shut up and code! :-)

At best, you have a user story:

As a Customer, I want a brand new Refer A Friend page so that I can invite my friends to join and receive a 10% discount

Actually, the real customer need behind this user story might tell you another story instead:

We really need to increase the number of our customers because if we don’t then we might be in big trouble pretty soon.

The thing is that the user story doesn’t tell you that.

Creating a “Refer A Friend” page is just an option amongst others to gain more customers. It’s no more than an assumption that this option will do the job. It has been chosen upfront by some business people. But what if they’d have asked you? Would you have chosen to create a “Refer A Friend” page or something different? At least I guess you would have brought some other options on the table.

It seems obvious but you cannot have options without knowing the goal to reach.

So to answer my own question: we don’t have options when it comes to software development just because we often don’t know the real goal behind a user story or some piece of specifications. We don’t know what really is the customer need we’re trying to fulfill when developing a new feature.

Usually, what is written is specifications or described in user stories is not a goal; it’s just a way to reach a goal, it’s just a single option an assumption that it will work.

Think about how things would go if military ground troops would act like developers. They’d receive their orders as specifications from the military command saying exactly what to do. A nice and clear step-by-step procedure, written a couple of months before the d-day in order to guide them once on the field. Just like a poor developer they would only have one way to succeed in hand, just a single option. But in the meantime things have changed. Once on the ground the troops got quickly caught in a trap. It’s not their fault, though: it was not written in the specs!

Military do the contrary instead: they mainly receive the goal to reach from the commanders. They might have some options to start with, but it’s also up to them to bring some new ones as the mission evolves. The commanders trust the troops! They know that they were trained to react and adapt the right way as things change.

To solve this problem in software development, well, there’s no secret: you’ll need to bridge the communication gap between business stakeholders and dev teams. Communication and trust are key to success.

If business wants to keep up with specifications, why not suggest going a bit further with Gojko Adzic‘s Specifications by example. This will help you to to cooperatively define the specifications based on real examples.

If you’re tied to user stories, then they should definitely sound like business goal instead of solution ideas (which is often the case). One simple way would be to find out two options that bring the same benefit. But an easier way would be to look into impact mapping where stories are not considered as commitments but options!

But the best thing to do might be to follow Jeff Patton‘s advice:

We don’t need an accurate document, we need a shared understanding

Discovering things collaboratively using Jeff’s User Story Mapping or Alberto Brandolini‘s Event Storming might be the best way to find options. Working together with business people will obviously let you know the real customer goal to reach.

Now take your shovel and dig up some options!

You’re brilliant? Stay humble!

17 July 2015 / one.hundred.acorns / Leave a comment

In France there’s a humorist who was really brilliant. He used to make everyone laugh while treating hot topics like religion, racism and such other hard-to-joke-with things. He was really smart. The way he was dealing with those near the edge themes was really impressive. This is really hard nowadays to be able to joke about those topics and he was doing it really well while condemning them and raising awareness.

But one day, for any reason, he crossed the line.

Everyone taught it was shocking on purpose; he was so smart that people taught he was only showing how much hate could be harmful! But he wasn’t… This feeling people had, thinking he was playing a role, only last a few months. Everyone understood that he was not that brilliant guy anymore.

He’s now banned from any TV show and many cities don’t even allow his to stand up in their theaters anymore.

But why am I speaking about that guy?

Well, it might be excessive but this story might be quite similar to things we experience in software development: Brilliant people don’t always deliver the right message.

I’m sure everyone knows someone brilliant. It might be your colleague, the one that writes code so fast and that knows everything. You know, the one that understands complex concepts faster than anyone and for whom everything seems so easy! Look around you, you see her/him, right? ;-)

It might also be someone you heard about. A book author or someone who invented something really powerful you use everyday at work or even someone who created a programming language on his own! Yes I’m speaking about all those brilliant few. The ones you almost don’t dare to speak to because you don’t want to ask stupid question and feel like an idiot!

Those brilliant people are so good at what they’re doing that if they state something than it might be the right thing to do!

But wait, what if it was not? What if those messages they were delivering were only good for people like them? Meaning they only apply to a few of us.

They are influencers. And being in that position, they ought to act accordingly. They must understand that delivering the wrong message could hurt a lot of people that don’t have the experience to argue against them. They will believe them, blindly.

When you have natural capabilities to understand quickly complex things or resolve difficult problems, do not feel like this is the case for everyone around you: it’s not.

A really well known brilliant guy did recently an anti Agile/Scrum talks that resonated with a lot of people. Because of who he is and because of what he has accomplished so far, he was considered as the messiah for many developers. But a majority of people who loved his talk forgot one important thing: this might be ok for him, but not for them!

This guy has obvious natural capabilities coupled with a lot of experience. But he forgot one important thing: brilliant people are also humble. Brilliant people are able to adapt their talk to the average level of the crowd. Brilliant people will teach others how to grow and improve themselves. Instead of thinking that because this is how they do this should also be everyone’s way; brilliant people know that things that might work for someone might not work for his neighbor; things often depend on the context.

The most important of all: Brilliant people do deliver the right message.

Eminent scientist, reputed programmer or even you, the one in the open space for whom everything is easy; if you want to be brilliant then try to be humble. Stop thinking that everyone is as smart as you are but do strive to help people around you become better.

The good enough software

28 January 2015 / one.hundred.acorns / Leave a comment

A couple of days ago, I was having a coffee with one of my colleague and he told me that:

“Almost every time we’re asked to develop a new feature, we provide our project leader with 3 ways of doing it: the quick & dirty way, the way we’d do it if we’d have the time to and, finally, the one in the middle: the way that allows us to meet the deadline doing something acceptable. Most of the time the later is chosen.”

Even if he told me that he was not so happy with it, he also said that it’s how it is and that they did not have the choice if they wanted to meet the deadline :-(

This plague has a name: the good enough software.

Kevlin Henney has a nice definition for this, here it is:

The good enough in good enough software refers to intrinsic quality: defect management, code quality and performance are not prioritized or managed as critical qualities. Deadlines end up being the focus, starting with initial time to market. While such an approach can appear to pay benefits in the short term, such an approach makes little economic sense in the long run — accidental costs and delays arising from quality issues come to define the development rather than features. (from InfoQ)

As a developer you should not provide 3 different ways of doing things. You should not jeopardize your projects by lowering the level of quality you’d like to put into. It’s up to your project leader/manager to strive to reduce the number of functionalities instead, it’s part of their job and this is where negociation is encouraged! As a developer you should always focus on defect management, performance and craftsmanship the same way.

This is why worse is better.

Worse is better has been coined by Richard Gabriel and as stated on Wikipedia:

The idea is that quality does not necessarily increase with functionality. There is a point where less functionality (“worse”) is a preferable option (“better”) in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.

If you do care about this, and I know you do, but your management don’t, well, quit your job :-)

And while you’ll be doing job interviews, please ask people you’re gonna meet this simple question: Is code quality taken as a corporate asset? You’ll know if it’s worth applying for a job there!

DDD is not architecture

13 October 20142 November 2020 / one.hundred.acorns / 3 Comments

While reviewing some résumés last week, my eyes were caught by this guy writing:

I’ve recently been focused on migrating to a DDD architecture

And some lines further:

Architecture redesign: Solution shifted first to MVC then DDD, multi-layered architecture implementation.

Apparently this guy tried to do some MVC but seemed not to be happy with it, so he decided to shift to DDD. This technique must certainly come from a secret chapter of Eric Evans’ Domain-Driven Design book that only this guy knows about! ;-)

Unfortunately this is not the first time I hear and see people confusing architecture and DDD.

A couple of weeks ago I went to a meetup where someone proposed to do a DDD Kata. I was quite enthusiast to participate and I started to imagine that we were going to do some Event Storming. Well, I must admit that I was quickly disappointed seeing the guy starting the kata by opening his favorite IDE. His idea was to do some code refactoring using DDD principles. To tell you the truth I was quite curious to see how he would manage to do so! The kata was similar to the Guilded Rose one; there was a lot of unreadable legacy code that you had to refactor to be able, at the end, to add a new feature without breaking the whole stuff. The guy quickly stated things like “as DDD tells us, let’s extract some interfaces so that we can put their implementations in another layer” Ouch! It took them some time (and a few remarks made by a couple of attendees) to realize that they were not doing any DDD at all.

So why do people keep on confusing DDD and architecture?

What I find as being the most likely explanation is that it’s due to the presence of the “design” term in Domain-Driven Design. But as Grady Booch says “All architecture is design, but not all design is architecture”.

DDD is not a technology; it’s a set of principles that will help you to deal with the complexity of an application domain by modeling it. DDD is focused on the domain and its logic where “Software architecture introduces structure and guidelines into a software system, leading to consistency and clarity” to quote Simon Brown.

But keep in mind that principles do impact your software architecture. Going with DDD will obviously lead you to choose the software architecture that will welcome it warmly. Architecture styles like Hexagonal Architecture or Onion Architecture will definitely help you to accomplish that as it will isolate the domain and avoid the business logic to be tightly coupled with any infrastructure related technology.

Should you go with DDD? Well, as it’s often the case, it depends! From my point of view it mainly depends on your domain complexity: the more complex it is the more you might benefit from DDD. But every choice comes with a cost; it will be up to you to evaluate the need and as Simon Brown says: “Principles are good, but make sure they’re realistic and don’t have a negative impact”!

Consultant et formateur
Si vous recherchez un accompagnement pour votre équipe ou une formation, je suis à votre disposition pour plus d’information, n’hésitez pas à me contacter !

Bridge the gap between dev team and business people! – Idea #4

7 September 20149 November 2015 / one.hundred.acorns / Leave a comment

This article is the fourth out of an unlimited series (let’s say at least 5!) where I’m gonna try to give you some ideas and easy things to put in place in order to bring your team closer to business people.

Written so far:

Value Stream Mapping

First time I discovered Value Stream Mapping was when reading the very interesting “Lean Enterprise” book by Joanne Molesky, Barry O’Reilly and Jez Humble. The final version of the book will be released in December but the early release version is available for download at a lower price since a few months now.

A Value Stream Mapping is a method from lean-management that allows you to quickly visualize the flow of value delivered from the genesis of a project until the customer delivery. It has originated from manufacturing but it can easily be applied on software development as explained in “Lean Enterprise“.

The exercise is pretty straightforward, you just have to write down all the stages that are necessary to bring an idea to its delivery and write under each steps the Lead Time (LT) and Value Added Time (VA). The Lead Time is the elapsed time needed to arrive from a stage to another and the Value Added Time is the amount of time really spent on that step where value has been added (the real work)

When working with huge companies where there are a lot of processes and departments, the exercise might take some time to accomplish as you’d need to meet people from all the different department involved in order to collect all the data. For us it was quite easier as it took us only one and a half hour to end-up with this:

(Pink post-it notes represent process stages, LT and VA are written under each)

First thing to do is to select a recent representative project (the kind of project your company is used to do in terms of size, people involved …) and obviously one that has been released to the customer! Invite enough people to be able to determine all the steps and find out corresponding LT and VA. We were only 3 to perform the Value Stream Mapping (a Business Analyst, the Head of Development and myself). As soon as all the steps have been found out, we used time tracking and reporting tools to get the exact amount of time spent on each steps (the VA) and when exactly those started. Some of the steps might be done in parallel and iteratively, that’s why some sticky notes are under other ones (in that case the corresponding VA is the sum of the whole column).

As soon as you have written down everything, just sum up all the VA’s and LT’s (some conversion might be needed here as some figures might be in days and other in weeks or months) and divide the total VA by the total LT to find out the Value Stream efficiency rate. The lower it is, the bigger is the chance to easily find some process improvement ideas!

The very interesting part starts at the end of the exercise! Well, you know, everyone might have in mind where usually things are stuck and where you might need some improvement to speed the value flow. But having the Value Stream in front of you clearly helps to focus.

The Value Stream is the perfect medium to start collaborating. Invite a couple of key people to join (from development and business side) and talk together in order to find out what could be improved in order to speed up the flow of value delivered and avoid wasting precious time. List out all the ideas and try them! Redo the exercise later on and check if the efficiency rate increased!

You will get a better understanding between all the stakeholders of how work moves through the company. People from different departments and having different point of views join together and collaborate to improve the whole company’s efficiency.

Mission accomplished!

Bridge the gap between dev team and business people! – Idea #3

10 July 20149 November 2015 / one.hundred.acorns / Leave a comment

This article is the third out of an unlimited series (let’s say at least 5!) where I’m gonna try to give you some ideas and easy things to put in place in order to bring your team closer to business people so that you can work collaboratively and efficiently with them.

Written so far:

Event Storming

In the previous post you read how Impact Mapping gives you the goal to reach and what are your options to do so, now it’s time to get more into how the system works.

An Event Storming session will involve almost the same people as for an Impact Mapping’s one but the aim is quite different!

Event Storming is about to find out all the events that occur in the system -> the business processes.

As Alberto Brandolini says:

Ideally, one would like to have participants coming from two fields: people with questions and people with answers. They provide the perfect mix of curiosity and wisdom.

Domain experts, the business people, know the system by heart and their job here will be to answer to a lot of questions! Those questions will be asked by a mix of different people (including developers, team leaders, testers, …), bring the curious ones!

After an ES session, everyone should be able to share the same vision on how the system behaves and the icing on the cake: everyone should share the same language to describe this (see the Ubiquitous Language).

First of all, you’ll need to find a big wall that you’ll cover with plotter paper or electrostatic sheets in order to be able to put sticky notes and maybe draw some lines and write text. Get some markers and different colors sticky notes. Decide to focus on a particular part of the domain (unless this could last more than a day!) and start by asking this simple question to your domain experts: “What’s the most important event that should occur in the system?”. If you’re working for a company that sells things on the Internet, and that you’re focusing on the ordering process, the answer should sound like “Cart checked out” or something similar. Now that you have that specific event, act as a time machine and try to find out together with the domain experts, what happened before this one. Write every single event on sticky note and put them in the right order.

Follow Alberto’s advice: Here’s the dogmatic color coding for #eventstorming follow it or perish! :-) (source)

This first part of an ES session really focuses on outcomes. Here’s a simplified version of what you should have:

CustomerLoggedIn->ItemSelected->ShoppingCartValidated->DeliveryAdressConfirmed->PaymentAccepted->CartCheckedOut

Now that you know everything that happens before a cart is completely checked out you can focus on the causality: the corresponding commands that lead to those events. Put another color – blue if you don’t want to perish ;-) – sticky note on every events and write the command name (you can also draw the actor that fires the command – User/Job/Time/…). Here’s another simplified version of what you should have:

LogCustomerIn->SelelectItem->ValidateShoppingCart->ConfirmDeliveryAddress->ValidatePayment->ConfirmOrder

Look what we have here? The method names of the not yet written application code! How could you be more close to business people if even your code speaks business? ;-) That’s the point where your code really brings business value!

And where the magic happens is when the QA tester can even start to write BDD styled tests during the ES session:

Given a Customer Logged In
When he Selects an Item
Then the Item should be selected in the Cart

I must admit this is a too simplistic example but you get the point, right?

At the end of an ES session every people involved knows exactly how the system works and behaves, what are the events that should occur and their corresponding command (and actor). You should be able to point out potential conflicts or missing concepts but new opportunities as well! Last but not least, everyone shares the same language and did speak together!

Mission accomplished!

Bonus: If you’re into DDD, Event Storming can even bring more than that as you’ll be able to find out the Bounded Context and Aggregate Roots of your system.

Bridge the gap between dev team and business people! – Idea #2

4 July 20149 November 2015 / one.hundred.acorns / Leave a comment

This article is the second out of an unlimited series (let’s say at least 5!) where I’m gonna try to give you some ideas and easy things to put in place in order to bring your team closer to business people so that you can work collaboratively and efficiently with them.

Written so far:

Impact mapping

One of the worst things about specifications is that they are boringly linear. They just tell you what to do, from point A to point B, no alternative. Have you ever seen specifications with options in them? nah!

Smart as they are, business people are nonetheless error-prone. Well, to be honest I would not want to do their job. It would be impossible for me to know exactly how the future will be and write this into documents weeks before any project start. Even if I’m currently working for a betting company I’m not used to place bet on what should coming on!

Impact Mapping is no crystal ball, it won’t tell you the right path to follow to reach success, but it will give you options! Impact Mapping is like a real roadmap, not the kind of roadmap that gives you only one way to go from point A to point B (as specifications do) but the kind of real roadmap that will tell you what are your options based on the current traffic jam and potential road works ahead.

But who’s gonna find those options? Everybody!

First interesting thing Impact Mapping brings, is that every people involved will share the same goal! With the development team having the same goal to reach as business have, is a key success factor. Think about a military unit engaged on a mission without having the main goal in mind, what would happen if something comes up that specifications had not anticipated? –> Fail!

Sharing the same goal will help people to find out options on how to reach it and one of the best way I know to do it is to make an Impact Map.

As Gojko Adzic says:

An impact map is a visualisation of scope and underlying assumptions, created collaboratively by senior technical and business people. It is a mind-map grown during a discussion facilitated by answering the following four questions: WHY? / WHO? / HOW? / WHAT?

The WHY? is obviously the goal I was talking about. The WHO? are the actors that can influence the outcome. The HOW? are the impacts, the options. And finally, the WHAT? are the deliverables, all the features that we might deliver.

Of course, everything should be measurable in order to be able to switch from one option to another if we see quickly that it won’t reach the goal. Like if your project management was switching from working with commitments on a linear plan to GPS navigation system that reacts to unexpected events!

Keep in mind that your options must be on a survivable scale, meaning that if it fails the project must stay alive! That’ why they must be measurable, achievable, realistic and timely!

When do you need to do Impact Map? Well, obviously before the project start so that you can define all the different goal-to-deliverable paths – the assumptions. But you should do Impact Map during the project as well to check if the chosen option is producing the expected impact!

When you do Impact Map, the first thing to focus on is the goal. If it’s too big or if it contains sub-goals, then cut it into milestones. Do not spend to much time on the What part, focus on the actors and impacts instead (and stay tuned for the next idea to come that will focus more on the What and how Business people could help there)

At the end, Business people will share their goal and everyone involved will think about the best ways to reach it. As Ron Jeffries said:

It shortens the communication lines between the people who want things and the people who do things.

Mission accomplished!

Bridge the gap between dev team and business people! – Idea #1

29 June 201430 June 2014 / one.hundred.acorns / Leave a comment

This article is the first out of an unlimited series (let’s say at least 5!) where I’m gonna try to give you some ideas and easy things to put in place in order to bring your team closer to business people so that you can work collaboratively and efficiently with them.

It’s no secret; one of the reasons why many projects fail is caused by the lack of communication and the weak relationship between business people and development teams. This often ends up with an application that do not look like what the stakeholders wanted at the beginning and it’s even truer if you work in an non-Agile environment (reinforced by the tunnel effect in traditional software development methodologies)

The main way, via which development team communicates with business, is through the holy specifications document.

But specifications, as holy as they are, suffer from one big problem. Theo Schlossnagle explained it during its “Responsibly maximizing craftsmanship in software engineering”‘s talk at the Craft Conference:

Specifications themselves are incredibly difficult to get right. […] Specifications are not written in computer language. They’re written in a horrible, horrible, language to describe something explicitly, and that would be… English! Or any other language that humans use to communicate. If you can write poetry and have two people feel different things when they read your poetry then it’s obviously not the right language to write specifications that are supposed to produce always the same output!

In addition to not being understood the same way by different people, they are often written weeks before the project starts and that obviously won’t help either…

As often, it will be up to the development teams to rolls up its sleeves and bring changes!

By the way if someone knows the reasons why business people are frequently reluctant to change, I’m interested to know. My two cents is that we’re moving faster wearing sneakers than formal shoes ;-)

Specifications seem not to be the magic recipe, so what else could we do?

Let’s discuss!

The first idea is the simplest to put in place. It might seem a pretty obvious one, but guess what? It rarely occurs! This idea came to me while reading the very inspiring “Notes to a Software Team Leader: Growing Self Organizing Teams” book by Roy Osherove:

One way to refuse stakeholder requests is by letting the requesting party realize for themselves that there are better ways to spend the team’s time. […] If your stakeholder wants feature X, bring them up to the walled task board with Post-it notes and say “OK, which feature do you want to move down in order to build this?” Ask them to take down a feature from the in-progress column or the to-do column. This usually leads to an interesting conversation with the stakeholder about what each task means and how much time it was estimated for. By the end of the conversation, either the stakeholder realizes where the task fits in or you will. Either way, what wins is the value generated for the company.

Easy! ;-) By simply asking the business girl/guy to come and discuss about priority, both parts will see things from each other’s perspective. This is a really simple technique but should really open your minds. Lead without being aggressive this should reduce frictions and tension pretty quickly! (and this will obviously work with any kind of backlog, you don’t need sticky notes!)

This is just one example, you should easily find other opportunities to discuss and exchange with business, collaboration is the key here.

This first idea is quite easy and straightforward to put in place, stay tuned for a few others to come, that might require more energy :-)

The Ubiquitous Language

20 May 201415 January 2015 / one.hundred.acorns / Leave a comment

Project Manager: -"Hey, I found a bug on that page" Developer: -"mmm, where exactly?" PM: -"There, the market is not displayed correctly" Dev: -"The what? Oh, you mean the football match name?" PM: -"Yes..." Dev: -"I see, I'm gonna warn the tester" Tester: [BUG2435 Status: Reported] The event name is not displayed correctly on homepage

Here’s the kind of familiar example you might hear every week. This short dialog illustrates one of the most common problems we experience in software development: people do not share the same vocabulary. In this brief example the different characters have used 3 different ways to name things. It’s easy to imagine that business people have their own way to name that too, and members within the same development team could have different naming as well!
This might not look like something really important here, but think about a more complex system that deals with concepts ways more complicated than a single football match. What would happen if people do not share the same vocabulary?

I had a colleague that had a 2 columns sticky note he uses as reminder where he wrote on the left side the word his team is used to use and on the right side the corresponding business term. Well, this might help but wouldn’t be easier to share one common way to name things?
The worse thing I saw was that brilliant developer. He was that guy in the corner. The less he was dealing with business people and the less he was bothered by someone else, the more he was happy. This guy was so away from the reality that he was inventing his own terms! This kind of behavior is extreme of course, but it illustrates quite well the problem. If people don’t share the same vocabulary, the code will be very hard to read and understand thus maintenance costs will increase… just for a matter of vocabulary.

I recently participated in an Event Storming workshop animated by Jef Claes & Tom Janssens at NCrafts conference. First aim of Event Storming is to talk with a domain expert and try to find out all the events that occurs in the system (Event Storming has many other benefits, but that’s a bit off-topic, have a look at Alberto Brandolini‘s blog here to learn more). We wrote the first events just after a short description of the subject by the expert. Those events were looking like “Shop Keeper Registered” or “Shop Keeper Account Updated”. After having talked a little bit more with the domain expert, it appears that the “Shop Keeper” term was not correct. The expert was using the “Partner” term instead. What if this was real life and that developers were keeping on using “Shop Keeper” instead of “Partner”? Let’s imagine the developer that needs to fix a bug on the Partner Registration process: he will search for any “partner” occurrence in the code and this will produce no result! He will need to struggle a bit to find the right place to fix the bug and then, he might add “Shop Keeper” = “Partner” on his 2 columns reminder sticky note ;-)

How could your code bring value if it doesn’t speak business?

Uncle Bob said that names in code “are the most powerful tool that programmers have to communicate with each other” and that “developers should use names to Reveal Their Intent and Avoid Disinformation“. Makes pretty much sense!

People often neglect the need to share the same vocabulary, they simply do not care.
Won’t you think that it would be easier for every person involved in a project to share a common way to name things?
What if the same vocabulary would be use from the business requirements to the software code or even the test code? Wouldn’t it ease the communication and the understanding of every one involved?

People always complain about communication between business guys and developers. Start by speaking the same language!

The Ubiquitous Language is the term used by Eric Evans in his Domain Driven Design book. The idea is to build a common language shared by everyone involved. As Martin Fowler said: “the language needs to be rigorous, since software doesn’t cope well with ambiguity” :-)

There are several ways to build the Ubiquitous Language, model storming and event storming workshop are one of them. But the successful ingredients of Getting-The-Ubiquitous-Language recipe are always almost the same:

find out the domains experts
put them in a room
ask a couple of colleague to join (another developer, a tester, …)
ask as much as you can about one specific part of the domain
put everything on sticky notes
it should not take more than 30mim
repeat until you think you’re done!

You don’t have to know about DDD in order to start Event Storming workshops.

One of the nice side effects of Event Storming session is that the more you’ll go deeper in details, the more you’ll see different part of the system naturally appear. You will get a pretty good idea of what components you’ll have to build (DDD speaking you’ll find out Bounded Context and Aggregate Root).
You will also be able to define your GivenWhenThens. As sticky notes are chained as events that must occur to get from one state to the other, it’s kinda easy to write your BDD styled tests! And that’s where having a tester in the loop is becoming interesting! Sounds like we have our 3 amigos meeting here ;-)

Hope all this gave you some ideas about things to try on your side in order to let you and your code speak business!

There are obviously other pretty good techniques to bring business and dev people close to each other but enough for now, I’ll have surely the opportunity to talk about this later in another post!