How do you teach DDD?

The more I work using Domain Driven Design in my daily job, the more I face how hard it is to teach. What’s the matter here? Why is DDD so often misunderstood? Of course, we can just consider that it’s a complex thing, hence requiring lots of knowledge and practices to be mastered. But let’s be more constructive and try to find the root problem in the domain of DDD teaching.

Like always, we need to agree on the terms we’ll use through this post.

Reminder: DDD

DDD is about tackling the complexity of the domain in the heart of software. It means that, in an ideal world, your software must be as complex as the problem it’s solving. Plus, the problem you solve must be the most valuable possible thing for your company. DDD provides patterns to address these points (spoiler alert: it’s not an easy task). Implementing DDD is all about analyzing dependencies.

Reminder: Tactical patterns

Tactical patterns are the most concrete parts for us developers because it’s about code! It’s a set of technical tools to concretely apply a DDD approach where it matters the most. These patterns evolve quickly, at the same speed as good practices. A well-known example is the repository pattern. Tactical patterns help to know how to build each part of a business.


Reminder: Strategic patterns

Strategic patterns are more abstract. They allow to categorize the domain (the business) into subdomains, in order to know how to build context of applications around it. Each context has a specific common business language (the ubiquitous language) and use precise way to communicate. Does a context impose things to another context? Do they share a kernel? How do they communicate? All of this can be captured using strategic patterns. They help to know what the different parts of the business are, and how they interact.


The DDD usual problems

Since I start studying DDD in 2012, I meet two recurrent problems.
The first is that newcomers (including me) do not know where to start. They can feel DDD is huge, but the reference books are intimidating. The community of smart peoples using words you never heard before seems nice, but you feel so stupid around them that it’s hard to stay.
The second one is that most people (yep, was me again) will not grab the duality of strategic versus tactical patterns at first glance. Worse, they may stay focus on the tactical patterns because they seem more concrete. We already know some of them, like factories or layered architecture. The consequence could be that we overlook the strategic patterns.

Root cause analysis

Following the principles of good design, how can we improve DDD so that these mistakes are harder to make for newcomers? Let’s use my (almost) secret silver bullet for that.
In my domain of DDD teaching, I believe there are two sub domains: one is about tactics, the other is about strategies.
An efficient implementation for teaching DDD would map one bounded context for strategic patterns. We have several clues to justify this implementation.
First clue: different languages. The two contexts have specific ubiquitous language.
Second clue: different life cycle. Tactical patterns evolve quickly. Most of the patterns from the blue book can be replaced by more recent patterns like CQRS/ES or hexagonal architecture. Strategic patterns are much more durable.
Third clue: the level of abstraction is not the same in both contexts.
Last clue: the strategic context is much more important. It’s my core domain, the core values I want to share when teaching DDD. There is a clear dependence between my contexts. Tactical patterns are important but will bring much less value if I teach them alone.
I now have a part of the answer about why DDD is hard to teach: it mixes two very different contexts. Both are useful, one is more central than the other, but also more abstract, hence harder to understand.

Solution attempt

Eric was really ambitious in his attempt to improve the industry, providing both strategic and tactical views. I think the trending and the emergence of major DDD conferences across the world are proofs that he succeeds. I also understand his willing to provide something that is not only abstract, to avoid the architect ivory tower syndrome.
Still, strategic and tactical patterns are really different beasts. These two faces of DDD make it harder to understand.
How can we manage this complexity? It depends on the context (did you see that coming?). But in the domain of teaching DDD for newcomers, I would accentuate on strategic patterns, mainly bounded context, because this is the pattern that can lead to all other patterns. Then I would explain that all the industry standards good practices (continuous integration, segregation of responsibility and so on…) are mandatory to implement the core domain, and that DDD also includes them under the name tactical patterns.
Trying to go the other way around (teaching the tactical part as introduction to DDD) increases the risk of missing the core concepts.

As always, it’s not a recipe, but it may be a way to facilitate the understanding of DDD.


The context of OOP and FP

If you want lots of reaction when you tweet, a sure recipe is to talk about Object Oriented Programming (OOP) vs Functional Programming (FP).

Let’s throw the cat among the pigeons, with another blog post on the Internet giving personal perspective on OOP vs FP. I’m far from being a functional expert. I code professionally mainly in C#, and sometimes in F#. I only play with Haskell and Idris in coding dojo. I’m not trying to convince anyone about anything. I just would like to share my thoughts about these two important paradigms.

And the first step would be to agree on what’s OOP and what’s FP.

What’s OOP?

To really grasp the philosophy, I highly encourage you to follow Alan Kay’s work. Of course, he’s not the only one behind this paradigm, but I find his explanations really clear. This keynote is a good start. In a nutshell, Alan has (beyond other knowledge) a PHD in biology. The way complex organisms are working is basically what inspired the OOP paradigm. In other words: collaboration through specialize components to achieve a complex task. Each component can be independent and don’t need to be aware of the full system. They just collaborate, receiving some messages when something was required from them, and sending messages when they have done something meaningful for the system. How these components communicate, and how the orchestration between them is managed is not imposed by the paradigm. And different languages have used different implementation. But this notion of independent component collaboration is the core concept of OOP. Not really what we see when we type OOP in duckduckgo…

What’s FP

Instead of looking for inspiration in the biological field, Functional Programming is rooted in mathematics. I’ll quote Philip Wadler to give a better definition:
A program in a pure functional language is written as a set of equations. Explicit data flow ensures that the value of an expression depends only on its free variables. Hence substitution of equals for equals is always valid, making such programs especially easy to reason about. […] Explicit data flow also ensures that the order of computation is irrelevant, making [functional] programs susceptible to lazy evaluation.”
What does he means? If I write X = A+B, or Y = C * D I don’t care about the values of A and B, or C and D. That’s a mathematical equation, it represents the concept of all the valid values for an addition of type A and B, or a multiplication of type C and D. Hence I can compose X with Y, and do substitution:
X>>Y = (A + B) >>  Y = X >>( C * D) = (A + B) >>( C * D)
(>> is the composition operator in F#)
If any of these values have the possibility to change (mutate) outside of my scope, all this reasoning is no longer true. Even worse if not only the values, but also the types can change. That’s why we say that in FP, we can write code only thinking locally. I know that my “equations” (or pure functions) are always true, no need to think about the rest of the world to ensure that.
Please note that this willing of “local thinking” can also be find in the “independent components” from OOP. But contrary to OOP, FP explains how it can be achieved, thanks to mathematics.

Which one is the best?

Finally, the answer the whole industry was looking for since many years. Here it is: none of them, because this is not the good question. The question should be: which one is the best in my context? And now we can start to talk. I think the answer is easier that what many believe.
The more constraints you have, the harder it is to write code that woks, the easier it is to maintain the code in the long term. What are code constraints? We have many of them depending on the language: syntax, immutability, no side effects, unit tests, types and dependent types for example. Is it better to write code faster or to have long term maintainable code? In a start-up context, I probably need to produce code quickly, until I find the good product. In a critical context where lives are involved, I probably want something robust, even if I need 1 year to write it. And of course, there are all the scales from “quick and dirty” to “mathematically robust” that might be your context.

Just tools

Functional Programming is by nature more constrained than Object Oriented Programming. Because it forbids mutability and side effects. When the language also uses types, it leads to powerful concept like Type Driven Development where we can, by design, remove the invalid states from our system, to make it more robust at runtime. And when the language also uses dependent types, we can even encode business rules into the types, to avoid compilation if a business rule is not met. As a drawback, it is harder to write. But when you achieve to write it, you can trust the famous quote “if it compiles, it works”. Maintaining this code is usually easier than a huge OO codebase, because thanks to pure functions we can use local reasoning to maintain the system. Please note the “usually” in my previous sentence. A “good” OO codebase can in theory have this property of local thinking, but the fact that side effects and global impact are not forbidden by design makes it almost impossible to scale (at least in my experience).

FP is hard to write, but easy to maintain (easier to reason about). OOP is easier to write, but harder to maintain (harder to reason about due to side effect).





This book is the second-best seller by Jason Fried and David Heinemeier Hansson. I’ve already commented the first one. It was basically one of the most pleasant reading experience I had so far, in terms of presentation. Knowing that they have written a book about remote working, I had it in my reading list since a while. As a remote worker myself, I was sure to learn stuff, or at least to discover another pleasant book to read.

William Zinsser’s touch

Like for Rework, we feel the hard work in this book to write only essential things, in the most comprehensive way. From the writing style to the chapters patterns and the images to illustrate them, we feel that nothing was chosen by coincidence.
The result is again a delightful experience.


Thanks to this writing style, clear and concise, the chapters follow each other with lots of takeaways. Short and actionable things you can do tomorrow, either as an employee or as a company, if you want to use and promote remote working.
There are also many arguments about why remote working makes sense, from a human and economical perspective. Including counter arguments to explain the challenges that arise with remote working.

Favourites takeaways

– You can work remotely just a few days per week, or even per month, it doesn’t need to be all or nothing
– Just staying in front of a computer is not working, the work is what matters wherever you are
– A demotivated remote employee is also demotivated on site
– On site or at home, we need a routine to perform
– It’s all about trust in the end

Should you read it?

If you are a remote worker or a company working with remote workers, this book will definitely be helpful. This is also true if you are interested by remote working, but don’t know where to start.
If you want to learn how to write a book which is a pleasure to read, this is a must read as well.

Have a good read!


Breaking people

An interesting discussion including  Yannick Grenzinger, Romeu Moura and Daniel Gonçalves has recently happened on Twitter. Thanks mates for the respectful and enlightening exchange.

It started from this:

The first objection was from Yannick Grenzinger:

Which, as  Daniel Gonçalves noticed, resonates a lot with an older tweet from Nicole Rauch:

I think the matter deserves a blog post to explain my position. Not because it’s the right position, but rather because we all have different experiences, with interesting things to share. I kind of agree with Nicole, and still I think we can survive it, if we stop trying to fix the system.

What’s breaking people?

The first step is to agree on what it means to “break people”. I was once, when I started my career.
We feel broken when we lost interest in what we are doing. When we stop trying to improve, because it seems excessively hard. We know that something better could be done. But we feel that whatever we can do will not have any meaningful impact. First, we lost our motivation, then our discipline, and finally our values.
Because what we can do doesn’t matter, it doesn’t matter either way if we don’t write a unit test for this code, or if we don’t take the time to refactor it. It doesn’t matter if the build is broken or if there isn’t any automatic build. It doesn’t matter if we ship bad software for unhappy users. That’s because of the corporation, not because of us. They want us to ship too fast. They want us to write crappy code. They recruit only juniors. They don’t care about code quality and good software. They don’t want to hear about pair programming. They just consider the IT as a cost centre. If they don’t want to change and see the world like us, there’s nothing we can do.

The global local impact

I’m a firm believer that you don’t change the world by imposing your view. You change the world by acting locally and leading by example. That’s exactly how I understand Gandhi’s mantra “You must be the change you want to see in the world”.
When I do consulting for a company, no matter how big it is, I start by acting locally. Of course, it would be easier to act globally. It would be easier if the whole company, at all levels, will follow the agile principles at once. But it never happens to me. And who am I to know the correct way of working for the whole company? I don’t know. What I know is how to write software efficiently. What I know is that it doesn’t belong to any managers to choose if we must write unit tests, or if we should use a build server and do code reviews.
Whatever the context is, I can keep my discipline and my values, which are mandatories to stay motivated.

But the system will break you!

Fair enough, that could happen, but at one condition. Only if I fail to recognize the moment when the “system” is creeping into my local safe area. I did this mistake once, and it won’t happen again.
Since then, when I do recognize this moment, I do whatever is possible to protect the safe area. The last possible solution is to abandon it and let it collapse.
Is it a big deal? Absolutely not. Our team could fail, our product could be shitty in the end, our company could re-create a command and control culture, but I (and the people convinced by my example) will be safe. Because we will leave and find another place where the culture is less corrupted, where it will be possible to manage a full project, at least locally, with our discipline and values.

So you’re just a coward?

I always clearly explain how I work during interviews. My behaviour will never be a surprise, as I clearly state that some practices are not optional for me to work.
Anybody who has already quit a gig or a job know how hard it is. Like every other passionate people, I have strong feelings about my job. And it takes lots of courage to admit that we’re no longer in the capacity to protect our local safe zone. It’s a failure. It is the proof that we couldn’t change enough people around us. But it doesn’t mean that we must abandon our discipline and values. It just means that we must abandon this toxic context, to find a better one.

How do you change anything if you left when it’s hard?

As it happens, lots of companies are looking hard for competent developers, with strong skills, discipline and values. It explains why, in 10 years of professional software development, I only need once to quit such a toxic environment. Since, I’ve always found some places where my discipline and values are much welcome.
I didn’t change any system so far, but I’ve done more important things. I’ve influenced the way of working of several people, in such a way that broken systems were no longer able to break them.

Changing things is not as important as changing people. From the latter, the first will happen.




Release your Soft Power

A few weeks ago, an interesting discussion arises on twitter (in french, sorry for my foreign readers).
In a nutshell, it all started from a (french) post by Arnaud Lemaire about why he hates developers contest, where he explained that this kind of behaviour is infantile. Thomas Pierrain explains why he agrees, and it triggers a long thread with many french crafters about:
– Is the IT industry mature or not?
– What is our responsibility as developers?
– What is the responsibility of the company we are working for?
– Can we change an organisation to improve practices? Should we?

Of course, I don’t pretend to provide any answers to these fundamentals questions, but as usual twitter is not the good medium for long discussion (even if in this case the thread was really kind and friendly). I would like to summarize my comments here, in english to be more inclusive because I guess these topics could be interesting for many software crafters across the world.

Is the IT industry mature or not?

I won’t comment much this point because I already explained here why I think it’s not. I understand that everybody has not the same feeling about it, and it’s fine. In any case I think we can agree on the fact that there is a long living software crisis, which at least shows that we can still improve by an order of magnitude.

What is our responsibility as developers?

Our responsibility is to be professional, which means that we must be aware of the good practices in our industry, and up to date with them. There are technical good practices (unit testing, continuous integration…) and soft skills good practices (good communication, reach the business experts, empathy with users…). Most of us are aware of the former, few of us are aware of the latter. When you do apply both, you are no longer a simple blue-collar technician. You become a business involved people, you release your soft powers. You’ll more likely be part of the important decisions. I think it’s what Thomas means in this (french) keynote when he talks about “changing your developer posture”: take your full responsibility to reach your full power.

What is the responsibility of the company we are working for?

Of course it is also a bit controversial. What if the company I’m working for does not allow me to reach the business experts directly? What if I can’t see any users? What if they don’t even allow pair programming, or unit testing, or continuous integration? That is the point where the company does have a responsibility. And the first answer is: try to change it with a local change of the practices.

Can we change an organisation to improve practices? Should we?

In the twitter discussion, many people testified about the fact that you can’t change an organisation as a developer, because you’ll need managers support for that. I do agree, and I don’t care at the same time. I’m a huge fan of Gandhi on this matter: “Be the change you want to see in the world”. Why would you change a full organisation? It was here before you, it will stay after you, and it would be pretentious to suppose that you know better than them for their whole company. But, as a professional software developer, you do know how to manage the software you are working on. This is where you can (and must) have an impact: locally. If your team, and potentially a few teams around are convinced about these practices, it should be enough to live with. And it’s not such a big deal if the rest of the company is not aware of these practices. A local impact is about improving the software quality through technical practices, and your co-workers’ life through soft skills.

Last question

It now raises a last question: what if the company resists change? What if they explicitly refuse technical and soft skills good practices? In that case my advice is really simple: leave. The world is full of companies looking for competent and passionate people. Leave and work for them, or even better: work for yourself as an entrepreneur, to create a place where other passionate people will be happy to work.


The Computer Boys Take Over

Does it already happen to you that a book is so good that you can’t stop read it? I’ve experienced it a few times. For H2G2, the Lord Of the Rings or the Dark Tower for example. But for the first time it happens with an IT book: The Computer Boys Take Over.

Why it resonates with me: the short story

What’s the Software Crisis? Is it old? Why do we have so few women in IT? Why our job is still not understood? Why are we often in conflict with middle management? These questions are very recurrent in our industry. I heard them a lot in many conferences and blog posts. This book provides answers, or at least good insights about the roots of these problems.

IT history

Did you learn about IT history at school? I didn’t, and that’s a shame. Learning about the first decades of our industry (roughly 1950-1980) is full of lessons. Many of us believe that our job is mature. It isn’t. Our job exists since less than one Human life, and the computer industry is undergoing a fast-paced evolution. Most of us didn’t even remember what happens ten years ago. It would be both pretentious and dangerous to suppose that our industry is mature. This book does describe the beginning of IT, and shows clearly that the software evolution hasn’t happened yet. The fundamentals problems we had 30 years ago (projects running over time and budget, low quality, unmanageable software employees, lack of resources…) are still relevant today. I would even argue that it’s more relevant today than 30 years ago, because of the explosion of personal soft devices.

The coders diversity

The book explains well how we (deliberately or not) build a male oriented industry. From the lack of consideration of the first developers (women programming the ENIAC) to the IBM PAT (Programmer Aptitude Test) ravages and the will to overcome the “lack of software developers”, we have all the keys to understand how and why women were not welcome for such a long time (of course we’re not the only industry to suffer this problem, which is not a reason for ignoring it).

The challenge for the management

Since I’ve started to work as a professional, I’ve always felt uncomfortable with middle management and huge hierarchies. I just feel like it’s a waste, and I can’t understand the fact that “Excel-Managers” do need to express their authority on me. And by the way, how can they have authority on me without understanding what I’m doing?  I read a lot of stuff about the “Y-generation” and experts trying to explain this fact. But this book also provides potential answers:  what if software does remove the need for middle management from the classical Taylorist understanding of work? That would definitely create tensions between the middle managers and the software developers. That would also explain why it’s important for these managers to keep developers in a code monkey position. “Please code, don’t think. We are here to think and manage, you are here to code and obey.”

The representation of developers

Another discussion that I often have with other passionate developers is the lack of representation of our job. Should we create a union? An association? Who could have the legitimacy for that? Another question that this book tackles. It explains that this was already asked a few decades ago. That’s what lead to the creation of the ACM (Association For Computing Machinery) and the IEEE (Institute of Electrical and Electronics Engineer). Most of us don’t know about them, and these associations have historical points of conflicts between the “pragmatic business programmers” and the “scientist software engineers”.

Software is hard to do

This book gave me many insights, and if you are a regular reader of this blog, you will probably recognize how it influences my recent thoughts about software. It helped me to have a deeper understanding of our industry, better than any other book before. Like always, I have now even more questions, which is the proof that this book is a must read for anybody with the will to understand the past in order to improve the future of the software industry.


PS: If you are wondering why such a great book has a title that may look sexist, please understand it is ironic. It highlights the fact that for many decades, these bunch of unmanageable weirdo nerds were referred as the “Computer Boys” (usually with a pejorative connotation).


Patterns of Enterprise Application Architecture

Patterns of Enterprise Application Architecture is one of the many interested books written by Martin Fowler. I have a lot of respect for Martin, mainly because he’s able to constantly challenge himself and improve his craft, since several decades. Here is what I like and dislike about this book.

A bit hard to read

Like Eric Evans, Martin Fowler has tons of interesting things to say. Unfortunately, both have a style hard to read. Mainly because it is dense in terms of content, but also because it is not concise. Let me be clear: I don’t pretend by any way to be a better writer than them. I just consider what they write as much interesting as it is hard to read.

Not totally up to date

Because the book was written around 2000, with many technical details, some of the patterns described are no longer relevants. Which is not that bad, because it gives an historical perspective. For instance, it was released when OOP was kind of marginal, and patterns like ORM were not widely spread. It is interesting to see what were the alternatives, and how OOP was perceived before to be mainstream.

A must read stay a must read

This book has greatly influenced our industry in the last decades. From this perspective it is still valuable, because it helps to understand what IT looks like in the 2000s, and how it evolves. The book contains also some seeds of the original ideas behind the emergence of Domain Driven Design, such as the Domain Model pattern. It allows to understand the original link between Domain Model and OOP, and thus the influence of OOP in the mythical blue book by Eric Evans.

 Thank you Martin for this book and what you do for IT since many years.




The Software Evolution Hasn’t Happened Yet

If the hardware has followed the Moore’s law, what happened to software? We have built assembler, and compiler, and high-level language. And now we have powerful machines, and all these shiny new languages and frameworks promising productivity. So why the hell are we still providing lame software?

The software crisis

According to Wikipedia, the term “software crisis” was coined by some attendees at the first NATO Software Engineering Conference in 1968. The crisis manifested itself in several ways:

  • Projects running over-budget
  • Projects running over-time
  • Software was very inefficient
  • Software was of low quality
  • Software often did not meet requirements
  • Projects were unmanageable and code difficult to maintain
  • Software was never delivered

That’s a good sum up of the problems I’ve met in 10 years of recent software development. And apparently, I’m not the only one, some of us talk about a software apocalypse.  It’s both confusing and sad to see that our industry’s perception hasn’t changed. What could be so hard about software? Why do coders write so much bugs?

The software labor

Software has always been, and still is, underestimated. Have you ever think about the names, hardware and software? These names reflect the roots problem of our industry. We believed that the building of physical electronical device will be the hard part. Nobody has anticipated the fact that programming these machines could be complicated. That’s why the first software programmers were women. We cannot be proud of that, it was just because some highly respected (male) scientists of the 50th believed it would be an easy task.

This fundamental misconception is still widely spread today, especially for people who never tried to build a software by themselves. It explains partly why our profession is underestimated and poorly managed. Very few people understand the implication of a “soft” device. Thus, they try to apply what Fordisme and Taylorisme has taught to them: hire some managers to manage an army of low qualified people to work on chain production.

The software engineering

Software is, by definition, not a physical thing. It removes constraints, physical and temporal. You want to change a past event? No worries. We can build rules, and break them as we wish. You want to change a behaviour? Let me add a few conditions. We’re not constrained by time or space. Not even by logic. We are only limited by our imagination. (And a bit by the computer power and the money we’re supposed to earn with the software. But as hardware is really performant, and because IT generates so much money, the main limitation is still our imagination.)

How do you build a bridge? By a series of calculation and drawing, taking in account a huge number of parameters from the physical environment, in order to use the laws of physics to assemble physical components in something that will stand for a while. But mathematical and physical laws do not apply to a soft world. A world where almost any rule can be broken. A world where the number of possible states can be greater than the number of atoms in the whole universe. Standard line of business applications have a complexity that we cannot manage (it is common for us to not accept this fact). And to add more fun, even if we manage to make it works pretty well, we are still not sure that it will solve any actual problem.

A doom’s profession?

Rather a huge opportunity I think, because software root problems are the same since many decades, we can be the actors of its evolution, and learn from our short history. From the easiest to the hardest, here are a few propositions to improve our craft. Sorry if some might seem obvious, but as a software professional, I’m in a good position to know that it is not.

Let’s start with the basics: automating tests. I won’t re-explain here why and how. But we need to acknowledge that it is currently one of the best way to manage this invisible complexity. A series of automated tests to validate the behaviours of the software as it evolves. It’s a way of feeling what we are designing. Like with WYSIWYG, we want to see immediately when an expected behaviour is broken, and what will be the impact of our modifications.

Another point is to use less states and more types, because it is where the complexity hides. Mathematically, specialized types do reduce the number of possible states in functions outputs. Solution like Property Based Testing can help to test the limits of such systems.

A harder way is to understand the problem we are trying to solve. There is no clear separation between the pure technic, and the design of an appropriate solution in software. Which explains why there can’t be a clear separation between the maker (the coder) and the the thinker (the system designer). To be good, we need to understand the business and to be technically efficient. This is where Domain Driven Design and relative stuff like Living Documentation can help.

And finally, we can learn and apply more maths in our code. It fundamentally adds some laws in our chaotic soft world. Some laws that will highly improve the code, like avoiding side effects and mutable states. This is where Functional Programming and TLA+ can help.

Think out of the box

Finally, we need to remember how young is our industry, and the fact that we’re living a crisis since the beginning. It means that we need more imagination to solve our problems. For that, I encourage you to listen to people like Alan Kay or Victor Bret, and to learn about our history. What if written software is just not the good way to make it? What if we are still living the dark age of software development?

We build a lot from (too) small foundations, maybe it’s time to challenge ourselves.


Of course the title of this post is a refererence to an amazing OOPSLA conference by Alan Kay: the computer revolution hasn’t happened yet.


Diverse IT

Here is another privileged white guy who stand up to talk about diversity. Let me explain why.

Google memo, Uncle Bob and the SoftwareCraftsmanship community

If you didn’t follow this thread, you can have few information here. The thing to understand is that it’s a big matter. There are lots of anger, misconception and bad explanations, between smart people. I would like to testify as the average privileged developer why I ignored this matter for so long, and what I decided to do to care about that. Because as Martin Fowler says, “you can’t choose if you hurt someone, but you can choose if you care”.

A long ignorance

I am a passionate developer, and I do respect competent people. I really don’t care if they are higher in hierarchy, if they are men, women, black, white, gay, if they believe in any god(s), if they have lots of experience or if they are juniors, if they drink alcohol, if they eat meat, if they wear suits or t-shirts… I just do care about how competent and passionate (the two are generally connected) they are.
And because of that, I believed that I had the good behaviour. I deal with everybody in the same way, that’s fair isn’t it?

A spark of light

But then I meet different people and attend to different conferences, especially in the Software Craftsmanship community, where I learn so much about this topic. And thanks to them I realized two important mistakes I’ve done: assuming that equality is enough, and assuming that I’m not legitimate to talk about it.


 The equality inequality

Treating everyone equally is great. But it’s unfair at the same time. If you were a woman in the twentieth century and won a Nobel’s prize, are you equal or better than other Nobel’s scientifics? From a pure cognitive perspective, you are probably equally smart. But to achieve the same scientifics result in this male world, you probably must fight much more. You must fight for your rights, to be recognized by your pair, much more than an average white man.
The same thing happens in IT today. We must acknowledge for example that to be equally recognized in our field, women need to work harder than men.


The legitimacy paradox

Because I didn’t feel legitimate on this topic, I didn’t talk about it. But because I never spoke about that, people like me might think they should not care about it either. Worse, it’s always the same legitimate people who talk about it. But what if they would like to talk about TDD or CQRS/ES instead?

What to do?

First, we have to be careful in our talks, especially in public presentation. Be careful about genders, when we use guys, he, craftsman and so on for instance… Of course, it is the same thing when we write blog posts and when we use twitter.

Every day at work, we can watch our jokes and behaviour. Watch other jokes and behaviours as well, learn to identify when someone is hurt, and let her (or him) know that you care and you will do your best to avoid that it happens again. And when we hurt someone (because everyone can make mistakes), we should just apologize. No need to look for excuses, just apologize. Uncle Bob unfortunately gives us a good example of what not to do recently.

As I already said, it’s important to speak about this, at work, in conferences and everywhere, especially if we are part of the privileged guyz.

It’s far from enough to fix the problem, but it’s a start, and at least, it shows that we care.



Thanks to the awesome Franzi who specialy helped me to grow up on this topic.


Explaining monads

If you have grasped the mathematical basics, and if you have understood what’s a monoid, you are ready to discover monads. Of course, we’ll continue to have fun with F#. There are tons of approaches trying to explain what monads are. Personally, I found out once I understood the problem they are solving, thus it will be the approach of this blog post. Again, the following code can be found online.

First compositions rule

Remember the function composition rule: “The result of each function is passed as the argument of the next, and the result of the last one is the result of the whole “.

It means that functions must be “pluggable” (the output of the first must be compatible with the input of the second).  But It also implies that we need a side effects free world. If one of the function can throw an error, there is no more composition because the result of my function (an exception is thrown) is not passed as the argument of the next, and the result of the last function will not be the result of the whole. Instead it breaks the runtime, and someone at a higher level (the caller) must deal with it.

Note that there is nothing to explicit the fact that isPositive function can fail in this code. It compiles as everything seems fine, but it can fail at runtime.

Sometimes vs Always

What if instead of thowing an error sometimes (if i >0), we always return a Result, which is either a success containing the value, or a failure?

I can wrap my result into something to defer the side effects. Of course it implies changing my signatures. My functions are no longer compatible, because a Result<int> cannot be used as the input by the isPositive function, it expects a simple int.

Bind to the rescue

What if I write a simple transformation function, that I can call bind. Its roles are:

  • In case of success: to wrap my simple int into a Result<int>, and to call the next function with the wrapped result
  • In case of failure: to return a failure, and not to call the next function, because after all, we don’t need to execute the next function if the previous one fails.

And now I can call this function between two incompatible functions and… Voilà! They are pluggable again!

My final composition will look like this, and this time it compiles.
Of course, you probably don’t want to create special functions to apply the bind. F# like many languages allow us to define a proper operator bind: >>= (it is the common sign for bind operator).

A more elegant composition will look like this:

I get rid of side effects, thus I can compose my functions.

Dude, you lost me.

No problem, take a breath and think about that:

  • I wanted to compose functions, but they have side effects
  • I wanted to get rid of side effects, thus I introduce the Result<T> instead of throwing an exception
  • My functions where no longer “pluggable”, thus I introduced a bind function to transform a simple type into a more complex Result<T> type.
  • We defined a new operator bind (>>=) to replace the explicit bind call
  • In the end I can have a nice composition, without the side effects

This can be resume by: we find a way to compose function, despite the side effects.

And where’s the monad?

Let’s decrypt the Wikipedia definition of a monad and see if something match:

“Monads allow developer to build pipelines that process data in a series of steps, in which each action is decorated with the additional processing rules provided by the monad.”

Sounds familiar?  In our case we had a pipeline (ToInt -> IsPositive -> ToString), and we decorated each step with the ability to convert from T to Result<T> (and to escape the pipeline in case of failure). You understand that we could have done other things in our bind function, such as Logging, Exception handling, IO management… We managed side effects in the bind used to compose the functions, instead of in the functions themselves.

“A monad is defined by a return operator that creates values, and a bind operator used to link the actions in the pipeline; this definition must follow a set of axioms called monad laws, which are needed for the composition of actions in the pipeline to work properly. The result of the last one is the result of the whole.”

I think we talked enough about the bind function. In our case, the return function is as simple as: return x -> x

Here are the monad’s laws: return acts approximately as a neutral element of bind, in that:

  • (return x) >>= f ≡ f x
  • m >>= return ≡ m

Binding two functions in succession is the same as binding one function that can be determined from them (in other words: bind is associative):

  • (m >>= f) >>= g ≡ m >>= (x -> (f x >>= g))

This is what these tests demonstrate:

Thus, the type we defined Result<T>, with the associated bind and return functions is a monad. The container alone is not a monad. The bind function alone is not a monad. But the container Result<T> with the bind function, because this function defines the identity function (i.e. a return function) when used with a neutral element, and because it is associative, is a monad.

Last words

Let’s finish the Wikipedia decryption:

“Purely functional programs can use monads to structure procedures that include sequenced operations like those found in structured programming. Many common programming concepts can be described in terms of a monad structure without losing the beneficial property of referential transparency, including side effects such as input/output, variable assignment, exception handling, parsing, nondeterminism, concurrency, continuations, or domain-specific languages. This allows these concepts to be defined in a purely functional manner, without major extensions to the language’s semantics.”

And because input/output, variable assignment, exception handling, parsing, nondeterminism, concurrency, continuations and DSL are very common IT problems, FP use monads a lot to manage them. I hope it is now clear for you how we used a monad to structure our chain of operation, and how we managed exception in a purely functional manner.

If so, you now understand what’s a monad, and why it is so useful, especially in FP. If not, please let me know and I’ll try to improve my explanations!


References: If you feel frustrated and want to go further, I recommand you the excellent Category Theory for Beginners, and the even better (but harder) Category Theory for Programmers.

IP Blocking Protection is enabled by IP Address Blocker from