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.

Discipline

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.

Love

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.

 

Remote

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.

Content

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.

 

 

 

Rework

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.

Content

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

would-in-the-past 

An echo from the past

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

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

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

An unexpected answer

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

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

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

imagesq1bg3pxm

Back from the Godwin point

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

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

learn-icon

Repeat the past

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

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

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

 happyending_dark_x2

Happy end

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

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

 

 

On Writing (Code) Well

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

41ebnx45bbl-_sx329_bo1204203200_

The arrogant guy

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

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

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

arroganceRewriting

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

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

the-essence-of-writing-is-rewriting

Decreasing the cognitive load

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

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

shutterstock_178355147-300x200Feedback

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

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

continious-feedbackThe developer/writer metaphor

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

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

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

 

Patterns, Principles and Practices of DDD

Patterns, Principles, and Practices of Domain-Driven Design was written by Scott Milett and Nick Tune. It gives a holistic view of DDD, from strategic to tactical patterns, and provides many examples to explain the concepts.

This book was presented to me by Bruno Boucard in this way : « It’s a very complete and modern view on DDD, and very few people have read it .» I agree, and it’s a shame.

millett_patterns_principles_and_practices_of_domain_driven_design

Why have so few people read it?

The more I read about DDD, the more I wonder if it is wise to explain all the DDD concepts, including examples, at once. It produces huge books (this one is 792 pages) contributing to the idea that DDD is complicated. It could discourage newcomers just by its size.

Also concepts and examples  do not deteriorate at the same rate.

Explanations about strategic and tactical patterns were quite the same as in the Blue Book. A few building blocks were added by the authors like Domain Events, but nothing really new emerges. It stays worthwhile to write about it, this content can stay up to date for many years.

DDD implementations on the other hand evolve a lot. The emergence of CQRS/ES and NoSql storage, the hexagonal architecture, and other practices have changed the way we implement DDD solutions in the last decade. These solutions did not exist in the Blue Book, and we can hope in 10 years it will be outdated by better alternatives.

domain_driven_design

But is it always good to have examples?

It is really hard to show examples, because DDD is contextual. It is courageous to show examples anyway, but I would not push them into production. I don’t blame the authors though, they wrote disclaimers explaining it is short examples for learning purpose.

My point is, it was interesting to write such a complete book, and I find it’s a shame it will be half outdated when we’ll find better way to implement DDD. Maybe it would have serve the authors to write better examples in a dedicated book, and keep another book to stay focus on concept explanations.

wooden_fence_png_by_camelfobia-d5kka26

Why you should read it anyway?

It is still a must read to have a modern understanding of DDD. It covers everything from integrating bounded contexts to implementing an event sourced aggregate and much more.

If you’re already familiar with DDD, it will improve your knowledge. If not, it is a very good start, even if you don’t grab all the subtleties at first.

 

 

Another article kindly reviewed by Brian Gibson.