Peopleware Review

This post is a review of Peopleware: Productive Projects and Teams (Second Edition) by Tom DeMarco and Timothy Lister

Peopleware is a book that I read with great expectation. It had been mentioned in other books and online review with high reverence so I was expecting much from it and it certainly delivered. A point to get out the way early on is that the book is really aimed at managers of programmers rather than programmers themselves but I still think it is a book that every programmer should read. The usefullness for programmers comes from a couple of things, firstly, that some of the points made can be applied to your home environment and projects and secondly it contains great ammunition for negotiating workplace practices and environment with your boss in the form of reasoned arguments and evidence from studies.

The book is written in a relaxed and casual style which makes for easy reading but doesn't stop the authors from bringing out dry statistics when required to prove a point. It covers a wide range of managerial topics, from building successful teams to setting up the most productive workplace environment.

I didn't end up making too many notes on the book, because of the irrelevence of some parts of the book to me in my current role, but the book will be a very useful reference to have on hand when negotiating about the workplace with managers. Some of the points I did find interesting and relevant enough to note down were:

• Failing projects are more often caused by sociological problems than technical ones
• Often projects spend too much time trying to get things done and not enough time asking if they should be done
• Most overtime tends to be followed with compensatory "undertime"
• "People under time pressure don't work better; they just work faster"
• People tie their self-esteem to the quality of a product, not the quantity
• Increased quality -> increased motivation -> increased productivity
• Parkinson's Law doesn't apply to work you enjoy ( and apparently the law was never backed up with any evidence in the first place)
• In a 1985 study, the most productive projects had no time estimate or schedule
• "The manager's function is not to make people work, but to make it possible for people to work"
• Music lessons creativity as they are both right side of the brain activities (evidence in study)
• The Hawthorne Effect: "people perform better when they're trying something new"#
• Think of a work team as a choir not as a football team

The point about developers (and likely people in general) tying their self-esteem to the quality of a project rather than the quantity is something I'll be trying to keep in mind at work. The quality required for maximum business value is often going to be less than the level a developer would be most proud of, so I'll have to remind myself of this when a manager wants to release a product when I would consider it too early. Though I'd be very happy if my manager took interest in the follow up point that better quality leads to better motivation leading to better productivity.

In conclusion, I don't think the average programmer will find too much of immediate practical use in Peopleware but I'd still recommend that they read it for the insights it provides into the workplace environment, it's usefulness as a negotiating tool with managers and in case they ever want to step into management. As with my review of Mastering the Requirements Process, this is the first book I've read on the subject, this time management, and so I don't have much to compare it to, but as a developer I feel that if a manger were to implement the suggestions of this book then I'd be a happier and more productive developer and in some cases the book contains the statistics from trials to back up this feeling.

Link to buy the book at Amazon.com

The Pragmatic Programmer Review

This post is a review of the book The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and Dave Thomas

It may be having read a number of similarly scoped books recently, or sitting next to someone who raves about this book but I didn't learn as much as I expected from this book. As mentioned, I don't actually think this is down to the book not being full of useful information and insights, becasue it is, but rather because the content overlaps with many other books (many of which were actually written after this book).

The Pragmatic Programmer has a very practical focus, most of the content concerns writing code from a  variety of perspectives, from architectural, through functions, down to line to line coding. The coverage is very solid and feels quite complete in it's covering of many areas, though as the Authors say themselves they don't go into deep detail in every area.

The things I found most interesting or new from the book were:

• The DRY principle not only refers to functions but also to pieces of knowledge or assumptions. You should only have to change 1 thing if these change.
• Comments that basically repeat the code break the DRY principle
• "Don't rely on the properties of things you can't control"
• Try and abstract away things like, which kind of database you're using, which OS, whether you're client/server or just client etc.
• Tracer code - develop an entire vertical slice to check it all works and you're on the right track and keep that code (different to prototyping)
• Prototype to learn
• Leave assertions on in production code
• Exceptions couple routines and their callers
• Encapsulate resources into classes using the constructor to allocate them and the destructor to clean them up. Means garbage collection will clean up resources and in non-GC environments it will help remind you to clean them up
• "Abstractions in code, details in metadata"
• Design for concurrency even in non-concurrent environments - makes temporal couplings obvious
• Software is like gardening 
• Don't try to refactor and add functionality at the same time
• "think of Unit Testing as testing against contract"
• "Don't use Wizard code you don't understand"
• When faces with a problem, write down all ideas no matter how stupid and check that whatever makes them stupid actually stands
• Organise teams around functions of the product
• "Failure to meet usability criteria is just as big a bug as dividing by zero"
• Test your tests by purposefully breaking the code
• "Find bugs once" write test to detect bugs that you discover

The idea of using metadata extensively in a program is a new one to me. On the one hand I can see it adding some complexity at first for the code that reads the metadata from it's source (the Authors highly recommend plain text files for many reasons), also adding complexity in that you can't tell exactly what the code is going to do without having to look at both the code and the metadata. On the other hand, there is the obvious advantage of not having to recompile your code when some program you're dependent on starts sending you 6 messages at a time instead of 5. Also I've come across many situations where test code needs a copy of the details that the production code doesn't expose which if they both got the details from metadata would reduce the number of  changes needed from 2 to 1.

The book has obviously been a success and the respect the community gives to the authors has allowed them to publish an entire range of books, with the Pragmatic moniker, the website of which is here http://pragprog.com/. It is a sign of the confidence the book inspires in me about the authors that I've now purchased another book from their range and have a few more on my Amazon wish list.

Someone who has read many books on general programming practice may only gain a few insights from this book, but for someone with little reading in the area then this book comes highly recommended compared to it's competition.

Link to Buy the book on Amazon