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.


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.


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.”


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.


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.


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.

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.

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.


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.
[cc lang=”csharp”]
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
[cc lang=”csharp”]
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.
[cc lang=”csharp”]
public class MyClass
private readonly MyRepository _myRepository;
public MyClass()
_myRepository = ServiceLocator.GetInstance();

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.


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.


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.


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.


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.”


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?”


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?


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.


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).


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.