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


In defence of defence of Software Craftsmanship and Uncle Bob

I hope some water has gone under the bridge after the “Google memo gate” followed by the “Uncle Bob is a misogynist gate”, so let’s discuss it again. During a few days, I feel almost uncomfortable to read Twitter. I read many anger reactions, many accusations and a few smart comments. I’d like to share my feelings in this post, because I believe I’m not the only one to feel bad about this thread.

In defence of software craftsmanship

I’d like to thank Daniel Irvine to have written a good post to defend software craftsmanship. I won’t rephrase here what he already said, but I would like to testify as a software craftsman. I came to this community explicitly because I was not looking only for technical excellence. And I think it is the case for most crafts(wo)men I know. It is an open minded and friendly community.
I feel that even more due to recent events, because at every new attacks in Paris, London, Barcelona or Turku, I can think to crafts(wo)men living here, and I hope nothing bad has happened to them. If I care about them it’s because I know we share some values and principles. Not only the quest for technical excellence, but also a deep respect for people, a willing to improve the things around them and to share their passion. I feel connected to them.

The software craftsmanship community is by far the place where I’ve met the more activists. They talk a lot about ethics, politics, environment, and of course diversity. I can’t remember a single SoCraTes I attended where several of these topics were not discuss. And it is important to me, because I know I must improve about them. Of course, it is not perfect, it is often the same people who talk about these topics. But please don’t assume that other people don’t talk about that because they are not interested. They don’t talk about that because like me, they are often part of a favourited majority, and don’t feel legitimate to discuss such topics. I know it’s wrong, I don’t try to justify it, I just try to explain how I feel, and why I need to change.
As a software craftsman, I would like to testify that this community is certainly not a bunch of old white men who care about TDD. To be honest, this is the community where I see the most diversity, in terms of country, sex, religion, and skin colours. I agree it is still not enough. But it is unfair to say that this community only care about technical stuff.

In defence of Uncle Bob

But I think we missed a post to defend Uncle Bob as well. I’d like to thank him for the many good, talks, books and blog articles he has written. He was the one who enlights the passion in me with Clean Code.
Of course, he has done some bad stuff as well (but who doesn’t?), and I don’t agree with every word he says. For instance, I don’t believe working 70 hours per week is mandatory to be a good software engineer. And no need to say I don’t believe that you should not fire someone who has toxic ideas.
But his point was more subtle: “Don’t fire someone just because you disagree with him”. I think his example and context was bad, but it raises a fundamental question: how do we differentiate toxic ideas and ideas we disagree with?  It’s a fair question because if we don’t agree with toxic ideas, aren’t we tempted to label as “toxic” any idea we might not like? How do we react with people who label agility, scrum, XP or craftsmanship as toxic?

I don’t have the answers, but my point is that the community has overreacted. Yes, the example was poor, yes, the context was bad. But instead of asking for explanations (that he writes here), and discussing the core question (how do we differentiate toxic ideas and ideas we disagree with?), there was lots of anger and unrational discussions about since when and how much Bob is a misogynist, and if we should refuse him to speak in conferences. Aren’t we open-minded? Aren’t we here to help each other? Uncle Bob is a master of technical stuff, but he says that he needs to improve on the topic of diversity. Like me, and like many other average white men in the industry.
The solution is not to ignore him and label his speech as “toxic”. The solution is to discuss, argue and teach, because we are all smart software engineers who share values and principles, including the willing to improve, and not only technically.

As a software craftsman, I would like to testify that this community is very open minded, and that it can help people to improve, even Uncle Bob.


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



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.


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.


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.


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.


The Technical Debt Myth

We assume that less design effort allows producing features faster, in the short term.  Less design effort generally means less abstraction, and tighter coupling, in order to produce working code faster.

But we tend to overlook the fact that it slows future modifications, even of unrelated features, because of tight coupling. We usually call this fact « technical debt », the term was first coined by Ward Cunningham. A better name was suggested by Steeve Freeman: unhedged call option.


Financial debt vs. Unhedged call option

Financial debt is predictable. You know how much you get, and how much you will pay back. A debt could be useful from a business perspective. A cash boost at the right time can create a major competitive advantage.

An unhedged call option also comes from the financial world, and is a really risky operation because it has unlimited downside. The buyer pays a premium to decide later if he wants to buy. The seller collects the premium, and will have to sell if the buyer decides to buy. It is not predictable for the seller.

Transpose to software, the difference with the concept of debt is the predictability in the amount of work required to fulfill our engagement.

When we write crappy code (tightly coupled and without tests), we collect the premium: we immediately get benefit from the new feature.

But as soon as we have to maintain or evolve this codebase, the option is called, and we have to pay an unpredictable amount of time (thus money) to achieve our goal.moneystack

Why? Who?

Every time this kind of tradeoff is required, we should ask who is asking for this, why, and who is going to pay it. Fun fact: those who ask for it (and directly benefit from it) are not often those who will pay it.

The sales team for example may ask for a quick hack because the customers « really, really need it yesterday ». But it may be paid by the production team, because next time the customer will want something, we still have to produce it quickly, without any regression. That’s where we will support more pressure, and may do some overtime.

In the end everyone will be impacted, because more pressure means more bugs, more regressions, and finally unhappy users. No company can survive unhappy users forever.

That‘s why good design matters. We want to produce current and future features in a sustainable and predictable way. sustainable_development_and_you

But what‘s good design?

We all try to do our best, but some of us lack knowledge and/or feedback. Plus, good design is contextual.

But regarding of our context, good designs have common points. It allows to think clearly about our software, and to evolve it easily. It allows to know where we should add/modify/fix a feature. The evolution-ability gives us an option on how to add/modify/fix this feature.

Software must be able to evolve because we know we don’t know what the software will be. We must design to be able to discover (as explained by Dan North in the 3 ages of innovation)

Decoupling is then required because we need to think about small parts in isolation, without side effects.  This kind of good design allows producing predictable software: robust, resilient and without regression when it evolves.

If we use shortcuts, and couple our code in order to rush it into production, we must be aware there will be an unpredictable amount of time to pay to get back into a predictable state.
It does not mean we should never do it, but we all have to understand this trade-off before asking for a “debt”.


What about speaking of predictability?

The more shortcuts you take, the less predictable your software will be. If you pay more for well design software, you get the opposite effect.

Unfortunately it is hard to judge, as we usually think we design software well. A good way to know if we are on good track is to rely on how predictable is the software we produce. Are the customers happy? The production team? The sales team? Do we have very few regressions? Do we produce features at a regular speed?

If not, we should consider investing more on design and refactoring, before entering into a vicious circle of unmanageable software.

Order Or Chaos Directions On A Metal Signpost

The technical debt Myth.

That’s why the comparison with a financial debt is sub-optimal. Money debt is predictable, whereas software debt is not. Unhedged call option is a better name, but still comes from the financial world.

Maybe we should stop financial comparison and speak of predictability instead. I find it is a better description of the consequences of shortcuts in the design.



Thanks Brian Gibson, always here to help me to improve!



We did not forget how to code

In a recent article, David Haney asks if we have forgotten how to program. I think not, rather we evolved.

We evolved from writing technical not so useful code to writing specifications.

Don’t misunderstand, when I am talking about specifications, I am talking about code. I am talking about coding crystal clear specifications even a computer can understand.crystalClearHow can we write “good” code?

Good code has two characteristics: it is useful for the business and usable for the developers. (usable in the meaning of Alexandru Bolboaca  and Johan Martinsson , for more information please refer to Alexandru’s book currently in writing, or Johan’s blog).

To write useful code, we need continuous domain knowledge crunching and refining. We want to avoid  technical stuff producing no direct value for the business.

To write usable code, we want to write code with clear abstractions, and easy navigate around these abstractions. We also want to replace/modify some code without pain.

From a business point of view, unless they are in a really specific context, they don’t need to know how to pad left. They don’t need to explain it either, because it’s obvious.

From a programmer’s perspective, we also rarely navigate in such an obvious low level of abstraction.designRewrite everything?

In most modern languages, these obvious and technically common operations are part of the core framework. Even if we know how to code them, even if it is quick to code, we don’t want to, because it creates no value for the business, and no usability for the developers. It does not make our code better.

 It’s dangerous to say « We should not depend on other libraries, we should rewrite what we need! » Where do we put the bar for « rewriting? »  Should we stop using NPM? JQuery? What about .NET and Java?    rewriteIt’s not the user’s fault, it’s the design’s fault.

That’s a core rule from UX translated to usable software design. We should always keep it in mind when trying to understand a problem.

The lesson from this “left pad” story is not that we should re-write everything to depend on nothing, but that NPM’s design allows a library to be deleted, or worse, to be changed.  

Imagine if Microsoft decides to change the behaviour of something widely used like String.Concat ? (or String.PadLeft if you lack imagination)

Asking every .NET developer to write these themselves is not the solution, even if writing a concatenation function is easy.

It’s unsustainable, a whole ecosystem cannot be built on an unstable foundation. If we want an ecosystem to evolve, we need a rock solid foundation.

This story shows how immutability is fundamental when thousands of users are depending on us.  

This kind of dependency, when hiding obvious stuff, is not necessarily bad. It’s more like solid roots allowing us to grow up.goodBadUglyDependency: the good, the bad and the ugly

The difference between bad dependencies (big frameworks) and good dependencies (little libraries) may be tricky. The key is: if the hidden part seems obvious to us and adds no value to our business, then it’s a good dependency. Otherwise we should prefer to rewrite it in complex contexts, because we will quickly be limited by what we don’t understand in our framework anyway.

This story should teach us that building an ecosystem is hard, and requires immutable, solid foundations. Please don’t re-write everything.

Let’s evolve together.


As usual, thanks to my kind reviewers: Brian Gibson, Jean Helou and Jérôme Avoustin


About hiring the best

A few years ago, three co-workers and I decided to work on the concept « hack your job ». We were convinced there was something wrong with recruitment and set out to find a technical solution. We wanted to find a better way to match great developers unable to find interesting jobs with great companies unable to find interesting developers. We concluded this problem required a human solution. Today, I would like to share a potential human solution to improve the recruitment process.


Disclaimer (edit)

I had some feedback accusing me to try to find a generic solution to hiring. As explained in conclusion, I don’t. My context is a start-up context with highly passionate and motivates people. I don’t claim the proposition I do here is generic, I don’t even claim it’s a good solution, I just assert this is how I would personally try to find great co-workers in my start-up.

I could even write a general disclaimer, I don’t try to teach anything to anybody in any blog article, I just give my feelings and experience.


What’s wrong with recruitment

I think the root cause is our mental bias for judgement. We believe ourselves to be good judges. We actually do it instinctively, anytime we met new people. Fact is: We are very bad at it. Humans are complex creatures. We can’t understand them within a few hours. It is known as the sampling bias. We believe a sample of time with someone will be enough to know if she is a fit for the job.


Military recruitment 

Daniel Kahneman is the psychologist who wrote Thinking Fast and Slow. In his book, he describes this error very well, because he did it himself. He worked on a team in the army to evaluate new soldiers. Their task was to determine if the soldiers would be good leaders (thus candidates for officer training) or not. They worked really hard to create a comprehensive series of psychologic and physical exercises to determine the soldier’s leadership skills. Tests were run over several days, the team’s confidence in the results they produced was high.

However, after a few years, the feedback they received was disappointing. Few soldiers they recommended for officer training were considered good leaders in the end. And many less recommended soldiers reveal themselves as good leaders.


Software recruitment  

Jeff Atwood recently wrote an excellent article on the topic. For him, software recruitment is wrong. I strongly agree and will reiterate many of the arguments and solutions from this article, adding my personal understanding and experience.

I see two general approaches to interviews:

Either we conduct an easy and short interview where how a candidate “looks” has a larger role than what they are able to do (not on purpose, but this is how our instincts work).

Or we conduct very long and complex interviews, often in several steps, lead by technical gurus. In this kind of interview, we believe we’re looking for talented people, but actually end up selecting technical clones of the gurus leading the interviews.

I’m not sure which one is the worst. With the first kind, chance is a big factor, but at least we may add diversity in our team. Maybe we won’t hire the best technically, but we will more likely find the disruptive employee with the ability to challenge our work. With the second kind, we will find people fitting our technical needs, while rejecting, more diverse candidates who just did not perform as well during the interview.


Hard interviews do not produce great candidates 

They produce great CV writers able to perform well under pressure. Are we hiring engineers for their writing skills? Do we plan to let them work under pressure ? Under pressure we can’t see the big picture, we can’t challenge and improve ourselves. We sense and react to whatever comes next. It’s not a professional behavior.

Removing pressure is the main goal of what I do almost everyday as a software developer. Unit testing, decoupling, context analysis…Whatever I do, I do to improve and manage my work in my context. Understanding our context and mastering the code we produce reduces the pressure we have to support.


How to find great candidates?

A software engineer writes code, with a team to solve business problems. An interview should be exactly that. Instead of simulating stuff, perform a selection based on the developer’s passion, as advised by Sandro Mancuso in his book. Can you find her on Twitter? On GitHub? Can you see some code she wrote? Is she active in local user groups? Any blogs? StackOverflow profile? None of that? Nevermind, take a coffee with her and find clues of her passion. Does she code at night? Any side project? How does she feel about new technologies? Does she realize we developers are changing the world?

As soon as you think you found someone passionate, find a way to work with that person for a few weeks. Jeff Atwood suggests asking them to work at night, or on weekend, or take vacation (if someone does that, it’s a clear sign of passion), and of course, pay them. Consider them as part of the company during this period, so they can really show you how they behave as software engineer. At the end, decide together if they are a good fit or not. You must especially hire them if they are better than you.


How to find great companies?

Be the candidate we want to work with. Recruiters cannot take the whole responsibility for bad hiring processes, candidates must adapt their behaviors too. An interview  is a two way process. The company learns about you and you learn about the company.

Show your enthusiasm, give some feedback to recruiters if you think their processes or mails are not that good. Show some respect and passion. Show your interest to understand their problems and how they plan to solve it. Be a Professional, always raise the bar. You can’t wait for the perfect company if you don’t try to be the perfect co-worker.


Hacking the interview

It is certainly not a perfect recruitment process, it is not meant to be. You still have bias, but by increasing the time sampling, you reduce the overall judgement bias and luck factor.

Fighting our biases, as candidate and as recruiters, is one of the hardest and most useful things we can do to improve our hiring process.


Thanks Brian Gibson , Clement BouillierAlin Dicu  and William Huart for the reviews and feedback.


Let’s be people centric

DDD, like agile and software craftsmanship, is very hard to teach.

We can explain concepts, describe patterns and practices, show some good habits. Still we can’t easily teach them, they are too large. The cognitive load is too heavy.

The consequence is that we usually focus on a subset of practices, and claim this is the essence of the principle. This is why some people believe DDD is tactical patterns, software craftsmanship is TDD and agile is SCRUM. It also explains why frameworks or simple patterns like micro services are over used.

I find this dangerous and believe it’s important to understand what these hard topics have in common. If we understand what is intrinsically hard in them, we may learn how to teach them in a more efficient way.information

It’s not about answers

It’s about questions. The three topics do not bring magic answers to our problem. They usually bring more questions. These questions allow us to evolve, to improve ourselves, and to dutifully accomplish our jobs.

They require being mature to accept that every answer we find will lead to more questions. They require courage and perseverance, but it’s worth it, because improving our habits will improve our professional life.darrell-fraser-quote-there-are-many-questions-but-no-answers

It’s not about a generic solution

It’s about context specific situations. There is a single answer to these three questions: What should we do to be craftsmen? What should we do to be agile? What should we do to be great DDD practitioners?

The answer: It depends.

What is our context? Do we work in a multinational or a startup? On a web or desktop application? In the finance or healthcare industry? The combination of all the specificities of our jobs is our context. For each context, different implementations are required.

What makes sense in one context is not necessary what makes sense in others. Every single architectural pattern coming out of Silicon Valley is not necessary a must have for your next project.


It’s not about technical stuff

It’s about people. The deep roots of DDD, software craftsmanship and agile are about people. Unfortunately, we mostly apply technical practices hoping to solve people problems, but fixing people is really hard.

Instead we should concentrate on understanding how they communicate and their particular business needs that are crucial to helping them create conversations

Should we stop talking about it because it’s easily misinterpreted?

Of course not, but we should be aware of this problem when we are trying to communicate these subjects. I heard more great advice from Liz Keogh at DDD Europe 2016 that we could apply here: “Don’t strive only for the ‘whys’, put some ‘whos’ inside.” When speaking of practices, don’t forget about the team, about the context, and about why we think they make sense or not for us.

This is how we could be more effective transmitting passion on these subjects. By speaking about what it brings to us in our daily work, others may apply it, if they recognize a piece of their own context in ours.

It took me seven years to realize that I shouldn’t be an evangelist trying to push what I think are good practices. Instead I should have contextualized for others habits that improved my professional work.


Let’s be people centric

Let’s stop being technical monkeys always defending what we know as the only viable solution.

Let’s improve our communication about deep topics like DDD, software craftsmanship and agile.

Let’s be people centric.


Great Thanks to Brian Gibson for helping me to improve my English writing.

IP Blocking Protection is enabled by IP Address Blocker from