Project failure is caused by human errors. Very few projects (if any) failed because they used PHP instead of Ruby. Projects fail because people fail.
Peopleware is about these teams. Your team. Why it might be failing it’s current project. And mostly what it can do to succeed.
This time I decided to resume the book using a mindmap. I really liked the experience and will definitely give it another go. It allowed me to write down ideas and reorganize them in a coherent picture of what I learned from the book. I believe it will help me remember the main ideas as well.
(Click to view larger image)
“Quality is free, but only to those who are willing to pay heavily for it.”
You can find the points I found most important in the mindmap. Still, I can’t keep silent on one point : quality matters. A lot. Even more than you think. A team that aims to be the best tends to be happy. The turnover rate is lower. On the other hand, asking the team to lower the quality leads to disaster – demoralization, lack of purpose…
Build a cult of quality in your team. Pay attention to details. About everything. Strive to make everything must be perfect. Doing so will push the entire team to aim higher and higher.
Last time I explained how the Pragmatic Programmer book changed the way I thought about software. This time I’ll explain how another book challenged me to look at how I learn and process information. What I learned in this book can be applied to pretty much any facet of life.
There is a lot more to the book – many of the subjects are only briefly covered but they allowed me to get acquainted with a wide range of models and techniques. It is up to you as the reader to learn a specific area of knowledge in more depth.
What did I get from the book? So far I got interested in the Meyers-Briggs personality test and in creative thinking techniques. I also added quite a few books in my TODO list from the bibliography. These days I always have a new book waiting to be read…
Pragmatic Thinking and Learning is aimed primarily to programmers and has a few analogies such as “debug your mind” and “refactor your wetware”. However the principles in the book can be applied to any skills you want to learn, from blogging to cooking. I strongly recommend it to anyone who likes to use their brain from time to time. Hopefully you’ll be interested.
There were lots of great advice under the form of catch phrase (DRY – Don’t Repeat Yourself, No Broken Window, the Law of Demeter…). The authors even wrote about usage of metaprogramming and compilers in (almost) everyday software. But that’s not what influenced me to become a better programmer.
What inspired me was that the authors have a deep passion for programming and it shows. They talked about investing in yourself as you would in an investment portfolio. “Learn a programming language every year”. “Learn your tools”. “Care about your craft”.
I first heard the expression “rubberducking” in this book as well – if you can’t find a human to talk to, talk to the duck.
However programming goes beyond coding. The code is important, but so is knowing your tools, the command shell, deploying an application in a real environment, build files and build automation. Programming is a social activity, you need to show your code to peers to get feedback and improve, you need to talk to your customer to know his requirements. You need to care, improve, learn!
That made me realize that the knowledge I have today is already obsolete – I needed to be aware of where the future might be heading, which technologies might come out on top in a few years. I started to read more books and blogs. I went to local user group meetings. I started a few pet projects in a few languages. And I realized that I would probably be programming even if it wasn’t my day job – I was just lucky to get paid for it.
If you haven’t read this book yet, it’s a must for every programmer who is passionate about his craft.
Thinking is a skill. Like any other skill it can be improved.
Six Thinking Hats aims at making your thinking process more effective by removing something that I rather enjoy but which makes any decision longer to come: arguments.
People do not use arguments because it is the preferred way. They simply do not know any other way. – Edward de Bono, Six Thinking Hats
I admit, I’m guilty… I’ve been in a few useless debates before. I’ll try to change now that I know another way…
Instead of arguing back and forth over an idea, it might be worth it for everyone in the meeting to gather information over a single axis at a time.
So when you explore an idea, you might want to wear a different hat to be sure to explore all sides. This can be done in group meetings or if you are alone thinking about a problem. Colors are used because they offer a neutral language which is easy to remember:
Blue: overall view, control of the thinking process
White: cold facts and information
Yellow: hopes, positive outcomes, advantages
Black: caution, warning, disadvantages
Red: emotions, feelings, hunches
Green: creativity, new ideas
The premise is that it is difficult to view all sides at once. In a meetings it gets worse because someone might be focused on finding what is good about an idea while someone else is focused on the drawbacks. Disagreement follows and it becomes a willpower contest.
A brief example
You do not have to use every hat for each decision. You might for example start with a blue hat to define the problem and the desired outcome. The you might gather as much information as you can about the problem (white hat). Then talk about the advantages of a particular solution (yellow hat). If the advantages are not what you expect, then just drop the idea and explore something else. No need to argue over a bad idea…
On the other hand if the idea looks good, then request everyone to put on their black hat and explore the hurdles that might encountered during the implementation.
Power of the team
So I invite you to think about the principles behind the book and try to find alternatives to arguments to solve problems. I know it can be fun, but arguments just are not that effective…
By focusing on each side separately, everyone is sure to have a global view and the decision is probably going to be easier to reach. Everyone is focused in a single direction at a time. Everyone is working together instead of against each others. If you’re a software development team, it might be time to act like one…
Thoughts about programming, technology and agility