Here we go for a review of Peopleware: Productive Projects and Teams, 2013 (1st edition in 1987) by Tom DeMarco, Tim Lister. Another long overdue review since I read the book twice again since I first decided to write this review.
This is a book about teams of software developers, what makes them produce exceptional software and how (for the management) to avoid being in their way of such a noble aim. To me, this is also the logical sequel to the Mythical Man Month (reviewed here a few years ago).
The core idea is that developing a software product is an intellectual work (of communication and reflection) in an environment (market and technology) that is changing fast.
I would group the other main ideas in the following categories:
- software projects are unlike traditional ones
- teams and motivations
- creativity and change management
This review is about a book I’ve received as a gift this year. It’s the transcript of a series of conferences given in French around the theme of civilization and organized by Carlo Ossola, Jack Ralite and several professors of the College de France: Great Civilizations[fr].
It’s quite easy to read and pretty interesting. The impression I got after reading it is that it supports the fact that civilization have in common at least two main characteristics two points quickly summarized in the rest of this article (not meaning to be original here).
To change my mind and also because I’m curious about all things related to ergonomics and user experience, I decided to investigate a little more seriously the field of UX which is quite trendy nowadays.
This is how I came to read the book Storytelling for User Experience by Whitney Quesenbery et Kevin Brooks about which I will make a brief review here (and which I came across in a mysterious way, maybe via an O’Reilly promotion).
I find the book well written and informational with some lengthiness though that are certainly due to the fact that I’m not exactly part of the targeted audience and also to quite a lot of redundancies from chapter to chapter (maybe on purpose, in order to make sure that some ideas remains on the reader’s mind).
Actually the most interesting feature of this book is that the author committed to eating their own dog food by illustrating each of their ideas with a story and also by making sure that the book is easily “browse-able” with a clear structure and concise summaries at the end of each chapters allowing a reader to jump over the ones that he’s not interested in.
In my recent exploration of software project management literature, I decided to look for answers to a question about Agile methodologies that has been bothering me for some time: the Agile Manifesto struck and somehow seduced me first and foremost because of its first statement: “Individuals and interactions over processes and tools” but all bits and pieces that I could read about Agile methodologies revolved around test-harnesses, continuous integration, sprints, iterations, daily scrums, kanban, stand-up meetings, etc. In short: it seemed to me that all agile-related resources were centered on processes and tools !
There’s an easy explanation for this situations: obviously processes are easier to describe, criticize and refine for the technical crowd I’m part of and, after all, the “agile processes” are designed to encourage interactions and relieve people from the inevitable dark side of software developments (bugs, requirement changes etc).
But still this puts “processes first” assuming that people will benefit from it in the second place, and that’s this kind of contradiction that motivated me to look for an “agile” book dedicated to the “human” aspects of agile methods, and ultimately to read: Individuals and interactions: An Agile Guide by Ken Howard, Barry Rogers.
This is a long overdue review of a long overdue read of the famous software project management book: The Mythical Man Month by Fed. P. Brooks, 1995 (1st ed. 1975).
I’ve heard about it several years ago, about how relevant it still was to current projects and more precisely how well it described what is systematically going wrong in software development. And all of that is true, impressively so !
Despite the vintage touch you can expect from a software-related book written at the dawn of software development (1975 !), the permanent disbelief of even the best educated developers toward the unavoidable occurrence of bugs and schedule slippage and managers’ natural tendency to look for manpower and neglect the productivity gains that could come from improving the information and tools available to a team, all of this is finely described and analyzed in this book.
Interestingly the author extended the book in 1995 to add more information and jeopardize his own previous assessments: answering some of his critics and reckoning some of his mistakes. This book embeds its own review !
This book is obviously a must read for anybody interested in project management and yet the first thing that struck me is how well the author characterizes the pleasure of programming, listing:
- the joy of making
- the joy of being useful
- the fascination for puzzles and minutes mechanics
- the joy of always learning
- the joy of working on “pure thought” stuff
In the following, I will try to categorize a selection of the main other arguments that struck me, into three categories: Planning, Development and Organization.