You might ask, why did I stop writing feedbacks on Craft Conference sessions?
It’s just because I post them on my company’s blog! :-)
Here there are: Abridged feedbacks.
By the way, as a foreign Craft Conference ticket winner, the guys at Prezi (one of the organizer company) asked me if I was ok to do an interview with them. The fact is that it changed a bit and it moved to I had to film myself during the conference.
It was real fun and here’s the result:
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:
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!
Jonas is CTO of TypeSafe a company that provides a Reactive Platform which helps to deliver responsive, resilient and event-driven applications. Typesafe spearheaded the Reactive Manifesto which defines a common vocabulary for reactive applications.
Unsurprisingly, Jonas presentation was about why and how to build a reactive application!
We’re entering a new era. When building an application we now often have to deal with mobile devices, cloud computing, distributed components. We need to build softwares that are real-time, responsive…
As Jonas said, our applications now have to react to:
In one word, they need to be reactive!
First of all, we need to go async! (see Amdahl’s law). We do need to avoid blocking processes (which kills scalability). An event-driven system makes use of asynchronous message passing which gives lower latency, better throughput and bring more loosely coupled components.
Our applications need to be scalable, meaning being able to be expanded on demand. Better scalability comes with systems that are built of isolated components that share nothing with loose coupling and that communicate asynchronously. We need to minimize contention and maximize locality of reference. One thing that need to be kept in mind while dealing with distributed computing is the 8 fallacies of Peter Deutsch: the network is inherently unreliable!
We also need to build resilient systems that are capable of recovering quickly in case of problems. We need to avoid defensive programming where errors are mixed with business logic and disseminated everywhere in the code. Our clients should only deal with validation errors, not with applications’ ones. Our services should be built both with a dedicated supervisor which role would be to handle things in case of issues. It should be up to the supervisor to decide what to do (kill, suspend, resume, …) and so business logic and error handling are decoupled!
Last but not least: responsiveness! We need to keep the latency consistent. We need to make asynchronous and non blocking requests and responses and switch from pull to push so that our UI’s are interactive and always synchronized!
Links:
one.hundred.acorns 