Developers don’t like people

Any idea who are William M. Cannon and Dallas K. Perry? Neither do I until a few months ago, and that’s a shame because they have a part of responsibility in the image of software developers. They have discovered that we don’t like people.

sans-titre

How do you hire for a new job?

Recruiters are still pretty bad to hire developers. Mainly because they don’t understand the job we do, despite the fact that software is everywhere in our lives. But imagine when software were not mainstream, they have to hire thousands of developers with absolutely no clue of what a developer is.

Still, big IT companies in the 50’s and 60’s have to find them, so they commissioned two psychologists (William M. Cannon and Dallas K. Perry) to look for the profile of programmers.

I bought the paper they wrote in 1966. It is interesting to note they were looking for happy programmers, more than good programmers. Indeed they use the Strong Vocational Interest Blank (basically: a MCQ to find your interest in different areas) to profile 1378 computer programmers. Then they build a scale to predict how happy someone could be as a developer.

happyprogrammer

Paper quotes

“Long ago, E. K. Strong, Jr. advanced the notion that individuals interested in the same activities and things, whether these were directly job-related or not, tend to find satisfaction in the same type of employment.”

“[…]it was anticipated that a new scale for measuring the interests of computer programmers might be developed. Such a scale would be especially valuable in counselling, guidance, and recruiting as a way of identifying appropriately qualified persons so that someone could say to them something like, “Hey, you there! Your future is in computer programming!”

“The interests of computer programmers were found to be most like those of optometrists, chemists, engineers, production managers, math- science teachers, public administrators, and senior certified public accountants.

“Responses of programmers to individual SVIB items, when compared with responses of other business and professional men, showed three things. First, they indicate that computer programmers are crazy about finding the answers to problems and solving all sorts of puzzles, including all forms of mathematical and mechanical activities. Second, they don’t like people — they dislike activities involving close personal interaction; they generally are more interested in things than in people. And third, they show a liking for research activities and a tendency to prefer varied and even risky activities, while at the same time avoiding routine and regimentation.”

“Although these scales can predict satisfaction in the field, they cannot tell us how good a programmer an individual is likely to be.”

pgmer

A fundamental mistake

I’m not a psychologist, but still believe this analysis have some serious errors.

I can’t understand where the conclusion that we don’t like people comes from. Worse, I imagine some candidates who might be rejected because they do like people!

This assumption hurts our industry a lot. The most challenging part of big software project is people management and communication. This is exactly what agile methods and practices like TDD, BDD, DDD and pair/mob programing are trying to fix since decades.

Assuming that we developers should not like people is a huge mistake, and denies the fact that good software is mainly a good team work. Maybe lots of happy programmers don’t like people, but there is no need to “like activities involving close personal interaction” to be a good co-worker. Trust, respect and honesty are usually enough.

Good programmers are good co-workers before all.

avengers

A shared responsibility: the media

Responsibilities are most often shared, no need to look for a single culprit. Media also take a part in the image of software developers. In every movie with a geek I remember from the 90’s, the geek was a stereotype of the introvert puny guy with googles.
Interestingly enough, our image has kind of evolves. There are more and more movies/series where we are the heroes. But there are still lots of efforts to do to improve diversity in our representation.

serie

A shared responsibility: us

This image has become natural for us too, and we might look for it when trying to hire a good engineer. Aren’t we skeptical when speaking with a good looking person in a suit for example? I guess we hire ourselves for a while, and are still assuming that the little guy with googles is probably a better programmer than this attractive girl.

So let’s take our responsibilities and fight our own biases, especially when hiring software developers.

 

 

Thanks Sylvain Chabert for sending me this article, it inspired this post.

PS: I don’t really know where to put it, but I really like Reinstedt’s discussion of the paper. Thus here it is (or at least a part of it)

“I’m reminded a little bit, since I did research on the Strong Vocational Interest Blank a couple of years ago as part of the Com9uter Personnel Research Group, of the supposedly true story that I heard in some work that I was taking in psychology.
The story is that in New York many years ago, during prohibition days, several psychologists from different disciplines of psychology–social psychology, religious psychology, social welfare workers, etc.–did work to find out why the people were on skid row, how they got there. The social welfare workers found they got there because they came from underprivileged, socio-economic homes; the religious counsellors found they got there because they had lost God along the way; and the other psychologists found different reasons why they got there. Prohibitionists said they got there because they turned to John Barleycorn. So it strikes me as a little more than interesting that certain results that I thought I would get, I got; and results which are contrary to these which Dallas and Bill thought they’d get, they got.”

 

 

IOC Containers, Dependency Injection and Service locator

Working mainly on .NET legacy project since a few years, I often meet the same kind of problems. One of them is a bad usage of Inversion Of Control (IOC) Containers, or Service Locator to magically access everything everywhere in the code. Just like a giant singleton.

I think these tools are not well understood. They are used as part of frameworks, or as a “good practice” without understanding the reason of their exsitence.

So let’s back to basics. images

What is Inversion Of Control? (IOC)

It is when Something control your code, instead of your code controling Something.

For example, when we need a library, we call it to delegate some work (like reading a mp3 file). Hence we control it.
When we use a framework, it calls us to manage some events (like user clicks on a button).  Hence there is an inversion of control.
inversion

What is Dependency Injection?

It is when dependencies are injected into a class, instead of this class managing its own dependencies.

For example, we often need to save something using a repository. The class has a dependency on a repository. We could directly instantiate the repository in our class. As a result, we won’t be able to write unit test on this class, because it will require a database connection, no matter what is the context.
Instead, we could inject the repository, to decide depending on our context if we want to inject a test repository or a runtime repository.
 injection

Why to inject dependencies into a class? 

In OOP, computer programs are designed by making them out of objects that interact with one another.
Dependency Injection allows to change the injected class implementation, hence the behavior, depending of the execution contexts (at least test or production). It creates relationships from high-level modules to low-level modules. It is an efficient way to apply the D from SOLID: Dependency Inversion Principle.

It allows to think about a given object in isolation (by isolating its behavior), and is really convenient for unit testing. Using our own class through tests is just dogfooding, and encourages us to write simpler classes with fewer responsibilities.

dogfooding-r-w1024-q75-m1414025204

How can we inject behaviour into a class?

There are three well known possibilities:

Setter injection
A setter with the required dependency in the (public) contract of the class.

public class MyClass
{
private MyRepository _myRepository;
public void SetMyRepository(MyRepository myRepository)
{
_myRepository = myRepository;
}
}

Constructor injection
The constructor is used to inject all the dependencies at once

public class MyClass
{
private readonly MyRepository _myRepository;
public MyClass(MyRepository myRepository)
{
_myRepository = myRepository;
}
}

Service locator
A class (the locator) is called to retrieve a service for us.

public class MyClass
{
private readonly MyRepository _myRepository;
public MyClass()
{
_myRepository = ServiceLocator.GetInstance<MyRepository>();
}
}

What is an IOC container?

Inversion Of Control Container is an unfortunate name for components managing Dependency Injection, in frameworks or libraries.

When we do dependency injection using a Service Locator, we explicitly call the service to get the dependency. IOC containers do dependency injection using constructor or setter injection, there is no explicit request. Here is the Inversion of control, supposed to justify the name.

It’s a bad name because we do not care about the concept of control here, the benefit is dependency injection. In other words, to understand IOC container, forget that they do IOC, just remember they do dependency injection.

dont-try-this-at-home

How not to use it

Here is a list of usage hurting maintenance and readability I saw in different projects.

– Usage of both Dependency Injection by constructor and service Locator.
Choosing one of the three Dependency Injection methods (constructor, setter or service locator) is up to your style of code, but mixing several of them makes it hard to think about the code. Be consistent around the project, the 3 methods achieve the same goal, there is no interest in mixing them.
The lack of consistency hurts the usability of the design.
As a direct painful example, the configuration for unit testing is harder, because some dependencies have to be mocked in the IOC container, some others in the service locator.

– Usage of a static singleton of service locator.
Singleton is probably the most used pattern, unfortunately it is not always wise. It is especially hard to write independent unit tests in this case, because all the dependencies are registered in the same instance of locator.

whisky_singletonsignature

Why to avoid Service Locator

The argument to use a service locator is usually that it reduces the pain for refactoring: the only dependency we have is the service locator, because the service locator can reach anything!
I believe it hides dependencies in order to write code faster. It literally means that each class could depend of anything. And the only way to know what the dependencies are is to look at the implementation.

 b_1_q_0_p_0cri4jaoj

Why to avoid Setter Injection

The main problem with setter injection is that the class is generally not in a valid state just after the creation. I hate when I can create a class, but it raises an exception when I try to call a function because I didn’t initialize the good values. I prefer to have explicit constructor, creating classes in a valid state, or not created it at all. I believe the role of the constructor is to ensure that the new object is in a valid state.

what-is-a-sql-injection-attack

Why Constructor Injection makes sense

I prefer to use IOC container only to instantiate the first classes for the system to start. From this point, I create manually other classes, and explicit all the dependencies in every constructor. Some would argue it is too verbose, but I see it as a guide.
When the constructor is too big, it’s a code smell encouraging me to think again about my design. Lots of dependencies implies lots of responsibilities.

And we know how to deal when a class has too much responsibility, don’t we?

 

To learn more on this topic, read the excellent work from Mark Seeman and Martin Fowler.

 

Thanks Thibaud Desodt and Thomas Pierrain for suggesting improvements.

 

Learning from the past

“As a principle objective, we must attempt to minimize the burden of documentation, the burden neither we nor our predecessors have been able to bear successfully”

“My first proposal is that each software organization must determine and proclaim that great designers* are as important to its success as great managers are, and that they can be expected to be similarly nurtured and rewarded”
* Understand designers as software engineers

“There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity”

“Adding manpower to a late software project, makes it later.”

“For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation.”

“The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and self-renewing. The secret is that it is grown, not built. So it must be with our software systems.”

“testing is usually the most mis-scheduled part of programming.”

would-in-the-past 

An echo from the past

All these quotes were written 50 years ago, in the excellent book: The Mythical Man Month.

Sometimes I think: “Waouh, we know this since more than 50 years, and we still have to fight for these practices in the companies I work for? Are we developer stupid people who don’t learn from the past? Don’t we try to improve our industry? Or maybe it’s just a French problem?”

quote-those-who-do-not-remember-the-past-are-condemned-to-repeat-it-george-santayana-162594

An unexpected answer

Unexpectedly, the answer comes from a discussion with my grandmother.

A few weeks ago, I talked with her for the first time about world war two. How it was, where she lived, what she saw.
Even if I know the History, I was choked when she explained me how Jewish people were parked in hotels, and how Nazis come to take them with violence, in places I know very well.
She was 13 at that time, she told me how a soldier put a machine-gun on her chest, yelling at her in German, even though she didn’t talk German at all. The soldier believed my grandmother was a Jewish kid trying to run away from the Jewish hotel. Fortunately my great grandfather arrived just in time and was able to save her. She told me many other frightening things.

I realized that, if my grandmother was more nervous, or if this soldier was less calm, or if my great grandfather was longer to find his daughter, I may not be here to write this post. I am lucky, but how many people did not have this chance? How many lives were broken because of racism and hate?

imagesq1bg3pxm

Back from the Godwin point

My point is: developers are not stupid, but developers are people. And most people don’t read, or even wish to learn. Most people unconsciously look for confirmation biases (including myself), about how things should work.

The less we have knowledge, the more we think we know. We can solve it by staying open and learning more, until we accept we know nothing.

learn-icon

Repeat the past

Most people believe that the past is the past, and that today is totally different. Most people don’t talk about world war two with their grandparents.

This is why nationalist parties have more and more influences in Europe.
This is why U.K. leaves the U.E. despite the fact that U.E. was the best invention against hate, racism and war since many centuries.
This is why the most powerful country in the world can vote for a racist billionaire to make America “great again”.

This is why I have to explain the things we know since 50 years in our industry in every company I work for (but in perspective, it does not really matter after all).

 happyending_dark_x2

Happy end

The good news is that it is easy to be “a good software engineer”: read, learn, go out of your comfort zone and always challenge yourself. Avoid people and methods who pretend to solve everything.

And to start learning about the History of software development, I highly recommend  The Mythical Man Month.

 

 

Readability

Much focus in our industry is on how we can write code faster. We want super productive IDE, high level language and huge frameworks to protect us from the hard reality of building software.

In my opinion it’s more important to find how we can write maintainable code by focusing on readability.

readability-tests

Frameworks

Lots of frameworks promise faster development by “getting rid of” the plumbing, this dirty stuff we don’t want to deal with.

Frameworks might not be too bad if they don’t hurt readability. But as they almost all do, the long term maintenance is a nightmare, because we have a new dependency. It is the classical 90% percent of time to fight the framework for the 10% of things that don’t match our use case.

By trying to write an application faster, we may lost our freedom to update our software when we want. Worse, we are constrained by some naming or architecture convention, making our code less readable.

framework-vs-library

Property Dependency Injection

The only argument I hear to justify dependencies injection by properties is: it is easier to write. And it’s a really bad argument.

It is much more valuable to be able to understand easily all the dependencies of an object. One of the best solution in an OO language is dependencies injection by constructor. It allows seeing quickly what are the responsibilities of a given class.

It’s really irritating to find out at runtime that I miss a dependency because it is injected via a property, or worse, directly by calling a static IOC container in an initialize function.

clean-code-ii-dependency-injection-34-638

Choose freedom

Instead of losing readability with a framework or other antipatterns, we can choose freedom. We must find lightweight libraries to match our needs, and not be afraid to write code. It will be more maintainable than a framework.

It is where a DDD approach makes sense: by identifying the core domain, we know which part of the system must be as pure as possible. But in a more generic domain, using a framework may be beneficial. As usual, context is king.

The core domain is the main value of our software, do we prefer a quick writing, or an easy reading?

everything-wrong-with-david-finchers-fight-club

The wrong fight

It’s appealing to believe that we should write software faster in order to improve the business we work for. I believe it’s a fundamental mistake. To be faster we need to make the software easy to evolve. And it evolves faster if we can understand quickly what is its purpose.

How many hours per day do we write code?
How many hours per day do we read code?
So why are we still writing new frameworks instead of focusing on clean code and readability?

 

 

Thanks Samuel Pecoul for suggesting improvements

 

A few myths about CQRS

I’m happy to see that event driven architecture rises in popularity, I already explained why I believe it makes sense. But when a topic gets more traction, we hear more and more weird things. Let me try to clarify a few myths about Command and Query Responsibility Segregation (CQRS) here.

cqsr_pattern

CQRS is not Events Sourcing (which is not Event Storming)

Some people understand CQRS/ES as a single architecture paradigm. It’s actually two different paradigms, even is they were brought out together .

CQRS is about segregation of the commands and the queries in a system. It is nothing but Single Responsibility Principle (SRP) apply to separate the decisions from the effects. It comes from CQS.

Event Sourcing (ES) is about storing immutable events as the source of truth to derive any state of the whole system at any time.

Both paradigms work well together (Greg Young calls them “symbiotic”). But we can do CQRS without ES, and we can do ES without CQRS.

And just because I heard the confusion a few times, Event Storming is not Event Sourcing. It is not an architecture paradigm. Event Storming is a way to crunch knowledge with the business in an event driven approach, but it is not technical at all. It is a convention to talk with other people using post-its to represent business events.

eventsourcingstorage

CQRS is not Eventual Consistency

Eventual Consistency is when the read model is not synchronously updated with the write model.

It could be challenging, but it’s not mandatory in a CQRS system. We can choose to keep things synchronous, when it is good enough. We can go for an asynchronous implementation when we meet performance issue.

Thus Eventual Consistency is about performance, not about CQRS.

keep-calm-and-eventual-consistency-4

CQRS is not noSql and/or 2 databases

When I asked Greg Young what’s CQRS, he asks me in return if I know the concept of a SQL View. A View is nothing but a projection of the data, optimized for reading. That’s the query part of the system.

Sure, we can choose to store the query part in a separate database. Yes, it could make sense to store it in a noSql database, to reduce the impedance mismatch.

But it is CQRS as soon as there is a logical separation between command and queries. The rest is just a technical choice.

vector silhouette of a girl with raised hands and broken chains

CQRS is freedom

CQRS is before all freedom in architecture.
It allows choosing if we need eventual consistency, noSql, synchronous or asynchronous validation, and so on. It’s not an extremely complex topic, only useful for Amazon or Google.

Of course, CQRS is not a silver bullet either, but so far I have seen lots of missing opportunities to use it in several domains. But I still haven’t seen a software using CQRS where they should have go for a simple CRUD system instead.

 

PS: I just saw Greg has written on the same subject in a  more concise and direct way 3 years ago.

PS2: If you want to know more, I’ll be talking about the synergy between CQRS, ES and DDD, at BDXIO next October the 21st

 

 

On Writing (Code) Well

Following an advice from Cyrille Martraire, I just finished reading On Writing Well: a non-fiction guide written 35 years ago. Reading this book helps me to realize there are lots of similarities between writing code and non-fiction.

41ebnx45bbl-_sx329_bo1204203200_

The arrogant guy

“A simple style is the result of hard work and hard thinking. A muddled style reflects a muddled thinker or a person to arrogant, or too dumb, or too lazy to organize his thoughts.”
On Writing Well, William Zinsser

I like this quote because who has never met a codebase much more complicated that what it needs to be? I was one of these arrogant guys not so long ago.

I was proud to write code that none of my co-workers can understand. It took me a while to accept that my code was bad, and that I overcomplicated it in order to look smart. It took me a while to realize that I had a muddled style.

arroganceRewriting

Another similarity is that it’s more about re-writing than about writing. No writers are able to produce a perfectly understandable story at the first shot. They have to write, and re-organize, and change, and remove things until it is clear enough to be shared.

Refactoring seems absolutely normal for a writer. But for a software engineer, we expect a perfect code at the first try.  We’d like to believe we are so smart that we can build a whole business process in our mind, and write it in an unambiguous way for a computer who doesn’t speak our natural language. But we can’t.

the-essence-of-writing-is-rewriting

Decreasing the cognitive load

We need to decrease our cognitive load, to focus on the really tiny portion of the whole business process we want to manage. Being able to reason about our code is paramount to high quality. And we can’t reason about our code if our brain is full of things unrelated to the problem.

In the same way, non-fiction writers can’t write a good article if their brain is full of things unrelated to their topic.

shutterstock_178355147-300x200Feedback

I see one big difference between writers and coders though: feedback loop. When writing non-fiction, it’s hard to know if your content is good before releasing it.

As developers, we have a very quick feedback using automatic unit tests.

continious-feedbackThe developer/writer metaphor

The house building metaphor hurts a lot our industry.
I think a better metaphor would be that writing software is like writing a book.

It’s something to remind our managers next time they want to add writers to solve our deadline issues.

Writing software is like writing a book with several other people, during several months, if not years.

 

A Craftsman work-life balance

I don’t feel comfortable when I hear people explaining how hard we should work to be “successful”. Mainly because “success” is subjective, it only makes sense in a given context.

For example, Uncle Bob in The Clean Coder asserts that a professional developer must work around 60 to 70 hours per week. 40 hours for his job, the rest of the time to improve his skills.

I deeply respect Uncle Bob, but when he says that I must dedicate 3 hours per day, week end included, from my personal time to improve my craft, I definitely not agree.
worklife-balance

Professionals have a personal life

We are valuables professionals with a really limited resource: time.

A company does not own 100% of our time because it fills a pay check. We don’t sell our lives, we sell our skills for a given period of time.

Investing on these skills is important. Learning new things is important. But it is unsustainable to do it only on our personal time. And when it’s done during our personal time, there are different things that can be done to keep an enjoyable life.

cat on beach

How to learn at work and stay efficient?

We can learn new things at work. Of course it does not mean we can play all day long with the last shiny technology when it produces no value for the company.

But we can do pair/mob programming. Whatever the job and the level of the co-worker we are pairing/mobing with, we will learn a lot of unexpected things.

We can explore new languages/tools on tiny internal topic. During a limited time (half a day? A few days?), we can pick an internal subject (improve the deployment script?) and try to solve it using an unknown tool/language we like.

It’s possible to organise 1 hour katas once a week. Or maybe to watch an interesting talk during lunch?

We can also switch a few people in the team on a regular basis. It will reduce the bus factor and spread good practices through the whole company
 b_1_q_0_p_0cb02vl5z-jpg

How to learn at home and keep friends and family?

When we think about it, we tend to realize there are lots of time we don’t use efficiently.

Work commuting is a good example. This travel time cannot be reduce. We can use it to read a book about the last subject we’d like to learn about. In car it’s possible to listen for audio-books or podcasts.

Waiting queue is another example. We wait a lot for: a plane, a train, a meeting, a doctor… It’s easy to keep a book, or better, a pdf on our phone to read instead of passively lose our time.

For sport addicts, what about listening some podcasts during the workout? It is true multi-tasking: the brain can listen to the podcast when the muscles are working on something different.

images

A crafstman work-life balance

I believe a good work-life balance is essential to be a software craftsman.

Personal life matters, it is the pillar to build a strong professional career. Not the other way around.

If people believe that they have to work 70 hours a week for their whole life to be professional, who will ever want to commit for a life career as a software engineer?

 

 

 

A path to escape the “No time for tests” death spiral.

We all know the “no time for tests” death spiral.

First we take exceptional shortcuts to ship something because “we have to ship it now but we’ll do better next time”. Of course next time we have even less time, we have to add features, we can’t really fix the shortcuts. It takes longer and longer to add features because of the shortcuts we took and cant’ remove. We start to invest a lot into fixing bugs.

That’s the beginning of a painful road for the team in charge, and we all know the end is bad. Some will try to work overtime to manage the mess. Some will burnout, tired of being so unproductive. In this hard time we’ll hear things like: “It has always been done this way, I know it’s wrong, but what can I do, I’m just a developer…”

No need to say I don’t agree, and here is the path I take as a developer every time I face this situation.

death-spiral

Step 1: Fix known bugs with unit tests

To introduce a quality culture in any company, start by adding unit tests every time a bug is identified outside of the development team (by the quality analysis team or in production).

When we talk about unit testing, people usually ask if it’s worth it. What’s the return on investment? How do you know what to test?

If a bug goes out of our team, we can’t afford to let it happen again. It worth it because a regression shows we are not mastering what we are building, and is really annoying for users. We know what to test because we have an exact failing use case.

Use this opportunity to introduce a build server, we want to know before shipping if we have regression.

jenkins.jpgStep 2: the tester strikes back with test first

Most people arguing against unit tests have this experience:
1> They write some unit tests
2> It is incredibly painful
3> They stop testing with the conclusion that unit tests are incredibly painful
(The official explanation is most likely: “It takes too much time to write tests”)

Truth is: writing good code is incredibly hard, writing bad code is freaking easy.

Testing our software do nothing but reveals the nature of our code. It reveals how it behaves when we try to use it. When the code is hard to test, the code is bad, that’s what we need to accept to overcome this step. No need to blame the tools or the methods. What we need is to learn how to improve the code in terms of decoupling and maintainability.

When it comes to an important piece of code, write the test first. It will lead to more testable code, because nobody likes painful things.

huretsjpg

Step 3: Test Driven Development as a rule of thumb

After a few months, if we do not observe any improvement, it is interesting to understand why? In my experience, it may be due to a lack of experience with unit tests (tools and/or methods) and/or a lack of discipline.

But if we observe an improvement due to step 1 and 2, it’s easy to argue that to improve even more, we should not ship any use case not covered by unit tests.

The good news is that our industry already uses an efficient method for that. It’s called Test Driven Development, and we can find tons of documentation online about it.

tdd.jpgStep 4: Less stress and better work

Be disciplined, don’t give up on TDD, and within a few months the results will be clear. The team will feel more confident and less stressed. With less stress, fewer bugs will be shipped, and we’ll have more time to improve, and to drink beers.

No overtime required. Only good habits, discipline and continuous improvement around good practices.

It is important to communicate at this stage. It may take several years to reach such a result. We should remember where we come from, what we did to improve and share our story with other teams.

zen

It’s even better when we’re not alone

Some help by someone who already took a similar path is gold, because she will point out what’s wrong in the code and how to improve it.
She will also be familiar with tools and can avoid silly mistakes we all do when discovering these practices.
She mights also know how to manage tricky managerial issues.

It is with this kind of expertise that such a path can be achieved in a few months, instead of a few years.

path

That’s what a developer can do

This path is not a myth, this path is not a theory.
This path I followed 3 times already, and every single time it helps me to gain confidence, credibility and to be proud of my work.

That’s the kind of things we can do, as developers, to change the way it has always been done.

 

Many Thanks Nelson Da Costa for the review.

 

Usable Software Diagram

“Who is the user of software design”?
Some Software Usable Design practitioners think that the user is the developer.

I think the answer is not the same in every Dimension.

kk-studio-1

The user of software design is the developer

Specifically in the Artefact dimension.
Maybe it was the first answer to come in mind, because the question was initially asked by some developers.
The developer uses the design to build a mind map (with abstraction and static representation) of the software. With this map, she is able to navigate through the codebase in order to achieve a feature or to fix a bug.
She will technically explain to the machine how it should behave, but other humans will need to understand these explanations. A good design will give a frame to help the developer to put responsibilities in the good place.developer-512

The user of software design is the final user

Specifically in the Runtime dimension.
If a user has to read our documentation, it is a failure and an opportunity for improvement.
The software design must be crystal clear for the user at Runtime, because she will also build a mind map (with dynamic representation) of the software.
Not the same map than the developer, because it has different purpose. But still the user will navigate in the UI thanks to this map, in order to achieve what is useful to perform her job.

add-user

The user of software design is the business

Specifically in the Decision dimension.
And the whole purpose of DDD is to bring back this reality as soon as it is forgotten in the Artefact or Runtime dimension.
Again, the business build a different mind map (with business use cases), and uses it in order to take decision. The goal is to improve the business using the power of software.

business-person-silhouette-wearing-tie_318-49988

Navigating with our own map

The map metaphor is really powerful, and Eric Evans himself uses it a lot.

I also like this talk by Simon Brown about the Art of Visualizing Software Architecture. He compares the drawing of an architecture with the drawing of a map. His point is that we need to know for who is our drawing, and why. Because any representation is an abstraction of the full system, and we need to understand what will be done based on our drawing to choose the good abstraction, at the good level.

Software design is used to navigate in the understanding of a software system. For this navigation to be efficient we want:
– a consistent level of abstraction
– abstractions align with our dimensionimages
Usable Software Architecture Design
A Usable Design needs to be navigable.
A good visualisation for our Software Architecture will let us know if our design is usable or not in terms of navigability.
Taking into account the dimension will help to build useful and navigable abstractions, because it implies a specific user in a specific context.

Don’t fall into the trap of mixing scale, or dimensions, in the same drawing. It will only result in a messy diagram that we’re used to see in our enterprises.

Instead choose one scale and one dimension to build understandable diagrams for one purpose.

 

Micro-service and bounded context clarification

One micro-service should cover one bounded context” asserts Vaughn Vernon.

It leads to an interesting tweeter discussion with Greg Young, Romeu Moura and Mathias Verraes.  Greg and Romeu disagree. I say it depends of the context.

To know if one can cover another, we must know what a micro-service is and what a bounded context is. I find their definitions are fuzzy, and I think this discussion is a proof of that. I’ll try to clarify my point in this article.

Disclaimer: the following definitions are based on my current understanding of DDD strategic patterns, I don’t claim they are the only true definitions.

twitter-messagerie-logo

Micro-service definition

We believe we know what is a micro-service until we take a look at the Wikipedia definition.

In contrast to SOA, micro-services gives an answer to the question of how big a service should be and how they should communicate with each other. In micro-services architecture, services should be small and the protocols should be lightweight.”

This definition is symptomatic of our industry: we explain something by something else we don’t understand either. Do we share a common understanding of what is “small” and “lightweight”? I don’t think so.

A better explanation is the second property in the details of the Wikipedia page: “Services are organized around capabilities, e.g., user interface front-end, recommendation, logistics, billing, etc.

To be fair, this property has lots of symmetries with how we define a bounded context.micro-services1-297x250

Domain definition and problem space

To understand what a bounded context is, we need to define what a domain is. It is a theoretical representation of a business, in the problem space. And it can be divided in sub-domains.

For example in the well-known business of Amazon,  the core domain is about selling stuff online, and there are different sub-domain more or less generic like shipping, billing, advertising and so on.

We are in the problem space because we have no idea (yet) about how we should implement Amazon’s business , it is just a theoretical description of what they do.

problem
DDD patterns that are applicable to the problem space (figure 1-4 page 10 of PPP of DDD)

Bounded context definition and solution space

A bounded context is a projection in the solution space to define boundaries in the system implementing the domain. Bounded contexts are important because they allow to define an ubiquitous language, valid within their boundaries. A product in a billing bounded context has not the same meaning than in a shipping bounded context.

When it is badly done, we obtain a big ball of mud, e.g. a huge system without boundaries where an update in the billing part may cause side effect in the shipping part.

We are in the solution space because it is an actual description of how we implement the domain. A bounded context does not necessarily matches exactly one sub domain. But having too many bounded contexts overlapping between different sub-domains is definitely a design smell.

solutionDDD patterns that are applicable to the solution space (figure 1-5 page 10 of PPP of DDD)

One micro-service should cover one bounded context?

Now that we defined micro-service and bounded context, we can try to decide if one micro-service should cover one bounded context?

And of course, we still cannot decide, because we still lack the (business) context. In some business context, a micro service might fit a bounded context. In some other, several micro services will be in one bounded context. The only thing we can suppose is that a micro service overlapping different bounded contexts has something wrong.

As usual in any DDD discussion, context is king.

 

For more thougths on bounded contexts and micro-services, there is this excellent podcast by Eric Evans.

 

 

 

 
IP Blocking Protection is enabled by IP Address Blocker from LionScripts.com.