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

 

 

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