The properties of great architecture

It is commonly said in IT, at least in Agile circles, that we can’t design software like we design building, using Waterfall approach.  Then we often said, including myself, that even if it works with the design of building, software really is a different beast. 
But have we asked ourselves how well this waterfall approach actually works for physical building? 

An architectural masterpiece

A few years ago, I moved to a little town near Lyon. During a walk, I accidentally discovered a very strange building. It basically looks like an enormous Soviet block, with no color and strange forms. I was really surprised because it was in a very nice place around, in the middle of a forest where you can do wonderful walk. There also was a very nice old fashion house in the neighborhood. And here stands this hideous block. My guess was that it was just something they inherit from the war, that the government gives away for charity (it is now a convent).
But when I was leaving the place, some signs for tourists explain to me that this is the famous “Couvent de la Tourette” design by the even more famous architect Le Corbusier. I hence accept that I just lack the sensibility to understand why this building is actually a piece of art, a masterpiece by a master architect, and not at all a Soviet block.
This was a few years ago, and I never think about it again, I may even have recommended this place to a few tourists in the region… “Do you know we have a famous building here?” 

Convent, la Tourette

Alexander’s point of view

One of my favorite things is to try to understand how people considered as pioneers were influenced to think as they do and come up with mind-blowing ideas, especially in the IT industry. How Alan Kay has come to think about Oriented Object Programming (OOP)? How the manifesto signers were influenced to think about Agile? 
And the one that leads me to this post: how the Gang Of Four has thought to design patterns? The short answer to this last question is: Christopher Alexander, another famous architect. In 1977 he co-authored “A Pattern Language” with Sara Ishikawa and Murray Silverstein. Of course the game does not stop here: how Alexander has come up to think about design patterns? 
I still don’t have the answer here, but fortunately Alexander likes to write, and has published The nature of order where he basically explains why, how, and when he thinks in this way, and try to give a few answers about the universe as well… 
Anyway, he criticizes lots of other architects in this book, including Le Corbusier, taking “Le Couvent de la Tourette” as an example of something very bad. He basically says that this block has nothing to do here, it doesn’t fit well in the place at all, it doesn’t care about the context. It was just an architect with probably lots of ego that draw it in his office, with his view of “modern” architecture, no matter if the place will be useful, or even beautiful. Funny enough, it perfectly fit what I thought when I saw this building for the first time, before knowing that a great architect has built it… 

What’s a great building then?

According to Alexander, either something contributes to the whole, either it doesn’t. I can only give you a hint of what it means, because the 1200 pages of the book are basically here to explain this concept of wholeness in depth. In a nutshell, he argues that the error of the last century architecture is to separate the building from its context, sometimes by ego, sometimes by greed, sometimes by ignorance. Because of that some people believe they can just draw something, and the technical implementation is not their problem. They are missing (and usually don’t want) a feedback loop. They think that they are smart enough to design a perfect thing up front. Because in their beliefs, the context doesn’t really matter. They underestimate the difficulty, because they miss the fact that this building will be part of a more complex system, and cannot be great by itself because it will or will not improve the complex system in which it will take place. 
Alexander thinks this kind of complex design can only be emergent and argues that this is how structure is built by the nature itself. 

Feedback loop, contexts, emergent design… Are you talking about Agile or what? 

Yes and no… Probably like you at the moment, I was thinking that I had found the source of inspiration for the Agile manifesto. And actually, it could be the case, because some of the manifesto signers were aware of the concept of design patterns, and thus somehow already influenced by Alexander. If by any chance a manifesto signer read this blog post, I would love to know if, at any point in the discussion, the name of Christopher Alexander was pronounced… 
Anyway, Alexander is also aware that what he describes in depth is properties of complex systems, and that activities like crafting software can certainly use many of these ideas as well. But he’s also aware of Agile, and even talks about XP in his book! For him, it’s not enough. There are these notions of emergent design and feedback loop, but he thinks we are still missing this concept of “wholeness”. And at this point, I agree with him. 

Dude, would you mind talking about software now? 

Here we go, Like Alexander, I do believe that his ideas applies very well in software as well, as in any complex systems. 
Indeed, we can feel that some programs are “bad” somehow.  The tricky thing is that we don’t have an objective way to judge it. We are missing this wholeness property. Some software is good, despite their lack of unit tests. Some software is good despite a shitty User Interface (UI). Some software is bad, despite the unit tests, the agile mindset, the pretty UI and the use of the last fancy framework or architecture style (yes Microservices, I see you!)  
This is because, in a complex system, what we feel as good or bad is the sum of many properties interlaced, that we can’t control or even enumerate. We can only feel them. Worse: these properties are different for each software, because they are highly dependent on the context. 
The same is true for physical building, still Alexander has tried to find high-level properties that usually fit what he considers as great structure. 
Then defining good software with practices or tool is definitely a failure. Your system won’t be great just because you’re building an event sourced system with a shiny framework in a functional language. 
It won’t be great just because you’re OOP code base is SOLID
It will be great only if both people building it and people using it are happy. Only if they feel whole when they use or build it. These kinds of software probably have high level common properties that we should strive to find. 

What’s on your mind about it? Can you think of any useful properties of such systems already?  


The Design of Everyday Things

Do you know a job hard to explain, hard to do and usually underestimate? Of course, I’m talking about the job of designer 😊
What do I know about it? Almost nothing, like anybody after reading a book. This book is the bible in this area: the design of everyday things, by Don Norman. Let me share with you a short feedback about it.

The design of everyday software?

As Scott said, like for any topic, “When you’re outside an area of expertise looking in, it can often seem monolithic and uniform, but when you’re an insider you quickly realize that there are many different subcommunities, each with different specialties and different approaches.”
I tend to oversimplify the job of designers, mainly because I lack knowledge about it. And this book helped me to understand something really important: building Software is Design, and we have tons of things to learn from their practices. And to be fair, people like Johan Martinsson and Alex Bolboaca have already talk and share a lot about this.
Basically, you can replace almost everywhere in the book “Designer” by “Developer,” and it still makes sense.

It resonates a lot with my daily work

This book is well written and a pleasure to read. It starts by talking about psychology, then about the fallacy of accusing the user before accusing the design. In other words, “Read The Fucking Manual” is not an acceptable answer, because who read the manual? People that are not able to use your product the first time, and still are forced to use it. When was the last time that you read the user manual from your phone or any online application, you’re using?
The assumption that a good design can remove the very risk of errors is absolutely powerful, both in design and software.
The end of the book talks about the (hard) collaboration with the marketing to build a product, and I’m sure it would remind you many anecdotes as well!

Go read it

This book is a reference in the design world but should be as much a reference in the software world. If you haven’t done it already, you can add it on your list of books to read!


The systemic failure of the IT industry

Let me tell you a story.
This is a story about a brand new software project, using last technologies and mobile devices, a really important project for BigCorp. They want to use this new product as a vitrine to show how good they are to create mobile applications.

The gold rush

BigCorp invests a lot on this project, quickly a team of 15 people was created. 1 project manager, 1 assistant project manager, 1 scrum master, 3 business analysts, 3 testers 1 architect and 5 developers.
Everybody wants to be in, the global mood was very good, all the requirements were clear, this will be the best project we’ve ever seen.

Sprinting to reality

After 3 weeks it was time for the first release… And the first deadline was missed. Less than half of the expected User Story were produced, and the code was really brittle.
During the retrospective (where project managers and business analysts were missing because they are busy) it was decided to do less automating testing and less refactoring, because it was obviously a lot of time invest in unproductive stuff. We need to deliver more User Stories.

Wall ahead

The project is now 1 year old. Half of the team was replaced. One of the business analysts was fired because he “screwed” up a demo to the company board. The mood is no longer that good. The requirements were not clear enough after all, it’s even hard to know who the users of the system are. The technology is no longer shiny because 2 new frameworks have been created during the year and seem much cooler.
The software is still really brittle, which leads to even less refactoring because “we don’t want to break it”. New attempt to add unit tests were made, but it “costs” too much, this is obviously “not possible for us to do unit testing”. Retrospectives were stopped, because who can afford one unproductive day?

And yet another awful legacy

The project is now 5 years old. No one from the initial team is still working on the project. The team is only 1 developer now, half-time. We ask her to “maintain and fix bugs” that users will find. The code is a nightmare to work with. We have no idea of what is done, and how it’s done.
It creates lots of frustration for the developer, and for the user.

Failure = lesson learned?

Not really, it’s just a normal software project in BigCorp. It’s actually so common that most people in BigCorp think that software projects are always going this way. From developers to the top management, no one is shocked anymore, this is how software project works.

What can we learn from BigCorp?

Software of big companies and governments are usually pretty bad. Because the product is just a mirror of the system that produces it. A system with lots of hierarchy, politics, arbitrary deadline and silos. A system with no idea of the level of communication and collaboration required to achieve great software. A system where the customer does not really exist, because the company is too big to care about them. A system that erases the creativity required for good software.

Most companies have systemic errors. They produce bad software, no matter how skillful the employees are, because the system pushes them in bad habits and make them believe that this is the only way to go.

This explains why it’s so hard to create good software. It’s not only about technical practices and principles, this is also a lot about the system in which this software is produced.

PS: Thanks to Anthony Cassaigne, and on the recommendation of Woody Zuill, I finally read the paper “Nobody Ever Gets Credit for Fixing Problems that Never Happened”. I highly recommand it, many echoes with this article !


The Road Less Traveled

“Confronting and solving problems is a painful process which most of us attempt to avoid. And the very avoidance results in greater pain and inability to grow both mentally and spiritually”. Does it remember you something? Root cause analysis, Domain Driven Design and so many practices in IT are about solving the problems instead of fixing the consequences. Actually, I think it’s the difference between a young and an experienced developer. The young dev wants to hack a solution as fast as possible. The experienced dev will use this time to analyze the problem, because when it is done correctly, building the solution will be “trivial”.
The passionate thing about The Road Less Traveled by Scott Peck is that it’s a book written by a passionate psychiatrist, drawing heavily on his own professional experience. It’s all about human relationships, and the incredible number of lessons from this book we can directly apply in our software developer job should be a huge warning for people arguing that we must be technical monkey.


Seems familiar again? That’s the very first section of his book. Through different experiences he explained how discipline is important to grow as an adult, and how most of us stay children. Each time we refuse responsibilities, each time we look for the easy solution instead of a more permanent one, each time we take a direct gratification instead of investing in a delayed but greater one, we are acting like children. This book brings us this hard truth: being an adult is not fun, and nobody will help or prepare you to become one. But fleeing our responsibility results in pain. That’s why discipline is required to grow as an adult, even if it hurts.


This one is a bit far away from software development, but important for mind growing. In a nutshell, the author tries to define love: true genuine love. Not the one you think to know when you’re 16 years old and discover the opposite sex. True genuine love is the unconditional love we have for our children for instance. This kind of love does not require anything from the loved one, it does not have to be mutual. It’s just something you give to someone. This kind of love is hard, and usually not what we’re used dealing with. It excludes the myth of “love at first sight”, because genuine love requires a deep understanding and respect of the loved one. The author explains that this kind of love is the one that can stand for life.

Religion and Grace?

The two other sections use some words that make me very careful… Religion, Grace… I believed this psychiatrist was a scientific man? But the reading was still really pleasant. The author is not trying to convince you of anything (even if he personally believed in god, or at least in something bigger than us). Again, he drew on his experience to relate some stories were religion drive people crazy. And some stories were these same religions literally save people. And grace is about all these things that we observe but can’t explain. What’s the link with psychiatry and psychology? Well, to be happy you need to accept that you won’t understand the world.

Yet another must read

It will not be the book that will make you a better developer technically. But we can feel the passion of the author through chapters, and his feedback on human relationships are priceless. It helps me to realize how much the job of a software developer is driven by people’s relationships, more than by anything else.

I highly recommend it.



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

William Zinsser’s touch

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


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

Favourites takeaways

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

Should you read it?

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

Have a good read!


The Computer Boys Take Over

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

Why it resonates with me: the short story

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

IT history

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

The coders diversity

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

The challenge for the management

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

The representation of developers

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

Software is hard to do

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


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


Patterns of Enterprise Application Architecture

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

A bit hard to read

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

Not totally up to date

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

A must read stay a must read

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

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





I discovered DHH during the « TDD is dead» trend with an ambiguous feeling. I highly value (smart) people with different opinions about testing, craftsmanship and software, but at first glance, DHH looks pretty bumptious to me.

Who’s this guy I’ve never heard of before who decides that one of my favourite development tool is dead?

TDD is dead?

First of all I listen to him and his arguments. I always knew TDD has limits, but rarely meet them. In a nutshell, he argues that TDD may hurts design. After some thoughts my feeling is that TDD does not fit well with invasive framework like Ruby on Rails. Does it make TDD or Rails dead? I don’t think so, they are great tools useful in given contexts.

DHH and I are not working in the same context. He’s more in the web fast app context, whereas I’m more in heavy line of business context (usually not even web). The good news is that his thoughts about my work’s style are less biased than people from my context.

Why I read it

I’ve a very simple way to select the books I read: the more I heard about it, the more it goes up in my reading list. I select rework in this way, without knowing DHH was one of the authors (the other one is Jason Fried).
It was a good surprise, and I definitely recognize his style, close of his blog. I also recognize William Zinsser’s influence, something we share. It is a really pleasant book to read.


The content is full of short take-away. I think I would gain more benefice if I read it a few years ago. Some advices sound clearly obvious now. Still I admit it wasn’t this obvious when I discovered the world of software and entrepreneurship in 2009.


Favourites take-away

–        Scaling is not mandatory
–        You need less than you think
–        Beware the workaholists
–        Go to sleep
–        Don’t confuse enthusiasm with priority
–        Pick a fight


Should you read it?

I think the book stay a must read, especially if you like the direct style of William Zinsser, and/or if you are both entrepreneur and software developer.

It helps me to know more about DHH’s universe.



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.



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.


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.


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.


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.


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.