Much of this book is spent explaining what should be obvious to the best managers, but which corporate culture and priorities tend to work against. In general, the book looks more at typical mistakes than at recipes for success. At the same time, the advice is solid and they often provide data to back up their assertions.

If I was a manager at a typical and mediocre corporation, I would not recommend this book too much-- it is hell fighting against corporate culture. However if you work for the best or you are starting a business and want to be the best, this book is extremely important. (If you are a manager working at a mediocre corporation, start your own business or get hired by a better company after you read this book!)

The main premise of the book is that people matter more than management or technology. Any business leader worth his salt knows these two points, yet most managers or leaders ignore them. This book helps give form to the ideals and specific guidance to get there. It is well recommended to everyone who manages software projects.

It's hard to find at Amazon a book rated with deserved 5-stars. Even harder if it's got a good review by Joel Spolsky. Peopleware is one of them.Simple language, short chapters with plain ideas inside and a touch of psychology, altogether produces a confusing feeling. It seems as if the book tells you nothing you didn't already know but there is where its power lies: you end up thinking that you could have written this book.

I've got the second edition which is splitted in six parts. The first one, it's a general and enjoyable review of what the hell managing people is and why it's so hard. After that, we're explained how our noisy office environment sometimes makes our productivity plummet. Don't worry! Low-cost solutions are also included. Next two chapters are both about people: how to hire the best and how to bring them up within productive jelled teams. Watch out, you must keep teamicide away from teams. It also talks us about CMM and what it calls "The Big M's", explaining its influence over creativity.Last but not least, this second edition adds several chapters dedicated to topics like chaos control, organization learning, process improvement...all of them from the corporation-level perspective.

All that stuff just to conclude that people is the most valuable resource in any organization. This book doesn't taste like one of those stale books about business emotional intelligence ...it just shows plain concepts and applicable daily ideas. What turns this outstanding book into a classic is that its principles can be applied to almost any project or business (related to IT or not). My piece of advice would be "if you manage people, read this as soon as possible".

So...bosses, Peopleware is waiting for you!

I was surprised at how relevant this book still is more than 20 years after its initial publication. Depressingly, it seems the authors' suggestions have not been followed by many employers. I recently changed jobs and am in a cubicle for the first time. I have been struggling to think in my cubicle, and this book confirms my suspicion that it is my work space and not my brain that is causing the problem. Even when I am not being interrupted, I am always slightly on edge wondering when I will be interrupted. The down side of the book is that the solutions and suggestions for improvements are quite difficult to implement. I just finished the book tonight - I wonder if I will do anything differently tomorrow because of this book. Probably not - maybe the fun part of the book is grumbling about our common work situations.

Great book on managing people and their space in a technical environment. A must for technical managers.

Quick enjoyable read. Some interesting commentary on team dynamics and the social problems teams encounter. I wish more solutions/suggestions were offered.

Nice reminder on what should we do during project.
We all know these things, but often we forget on them.

I expected the book to contain practical advice. The book covered many undesirable situations and business settings. There were no recommendations made on how to improve a bad situation. The book merely reported on the bad environment. If you are in an unpleasant work environment and want to know there may be others worse off then you, you may like this book.

I expected the book to contain practical advice. The book covered many undesirable situations and business settings. There were no recommendations made on how to improve a bad situation. The book merely reported on the bad environment. If you are in an unpleasant work environment and want to know there may be others worse off then you, you may like this book.

This book is a collection of short essays on how real people's productivity in software industry is affected. It is about human aspects of software development. There is a great variety in the material for such a small volume (about 250 pages). For example, it covers this:

1. The key to software development is people. People are not drones nor they are easily replaceable. They work by themselves and require not constant pushing, but careful motivation. If you don't trust your people you are in trouble. People are a capital investment.

2. Mind-intensive jobs require concentration, hence a private and quiet environment. Breaking the worker's flow leads to frustration and dive of effectiveness.

3. Teams require efforts to form and keep running, but the effect could be miraculous. There is nothing that could stop a running team. (Btw, I tend to call this a locomotive force myself).

4. Methodologies (the big-M ones) don't matter, same for the processes. Technologies and stuff, they never replace people who really understand and love what they are doing.

The book is of most interest to project managers or even upper level managers (may all our managers follow these advises please ?).

What can you do with the book being a software developer ? Not much, just look around and see if you like it where you work now. And take actions.

[quote]
If you've smiled ruefully at any of the characterizations in this book, it's time now to stop smiling anf start taking corrective action. ... It's supposed to be productive, satisfying fun to work.
[/quote]

The second edition differs from the original book in that an all new part VI is added, a few short chapters. Written many years later in a perceivably different tone. It's not just that the authors admit in its preface

[quote]
The first five parts were written by two yongish middle-aged consultants who spent most of their time working at the project level, part VI is written by two gnarled and grizzled old consultants who now spend appreciably more of their time working at organizational levels. ... Part VI is concerned with with the design of entire organizations that include development work.
[/quote]

but it is also that it is written in less confident and undoubted way. I see it as good, after all there is no universal truth, it is all just a food to the reader's thoughts.

And this is a great food too.

Providing an overall rating for this book was extremely difficult, and writing this book review was not an easy task. This difficulty is due to the nature of "Peopleware". This DeMarco work enjoys what appears to be a solid 5-star rating, and to some degree this is a very reasonable collective assessment. Without discussing at length all of the reasons I think this book should instead be assigned less than 5-stars, I think my reasons fall into two categories: (1) the original work was penned in 1987, and due to the industry pervasiveness of many of the ideas presented by the authors, a lot of the material can no longer be considered extraordinary, and (2) the cohesiveness of each chapter and the flow from chapter to chapter is less than optimal - in other words, it is a bit choppy. Now I realize that there exist many in the software industry that can gain great strides in their respective workplaces by reading this book and understanding how best to apply the provided advice, which is why I give this work 4-stars rather than 3-stars, but I must say that I was just disappointed by all the hype about this book, from a year-2007 perspective. And simple math obviously will conclude that 20 years have passed since the original publication. The 8 new chapters added by the authors in 1999 really do not communicate many ground-shaking ideas. In my opinion, Chapter 33 is the only one of these new chapters that personally provided me any insight. And the premise of this lone chapter is simply that "the ultimate management sin is wasting people's time". The simplistic line graphs that accompany this chapter provide some substance to the discussion about project staffing, but again this chapter still seems to be geared toward individuals who do not bother to keep up with the insight shared in industry periodicals. Despite all of these drawbacks, however, there are some strong areas of the book that are worth reading by all software industry professionals. These strong areas are more comparable to the content of timeless classics like "The Mythical Man Month", "Waltzing with Bears" (also by DeMarco and Lister), or "Death March" (see my reviews for all of these books), and are worth reading even if just to provide discussion starters within your organization. These chapters include "Vienna Waits for You" on working smarter and project deadline pressures, "Quality-if Time Permits" where the authors state that "Quality, far beyond that required by the end user, is a means to higher productivity", "Parkinson's Law Revisited" on estimations and productivity, "You Never Get Anything Done Around Here Between 9 and 5", "Brain Time Versus Body Time" on understanding the work day of a technology worker, "The Self-Healing System" on process, and "Teamicide" and "Open Kimono" on team jell. Realize that there are 34 chapters in this book. The bottom line is that this book on productive projects and teams, targeted at a software industry audience - although perhaps not overly impressive from a holistic perspective - is still heartily recommended.

Providing an overall rating for this book was extremely difficult, and writing this book review was not an easy task. This difficulty is not due to my skills as a reviewer but is instead due to the nature of "Peopleware". This DeMarco work enjoys what appears to be a solid 5-star rating, and to some degree this is a very reasonable collective assessment. Without discussing at length all of the reasons I think this book should instead be assigned less than 5-stars, I think my reasons fall into two categories: (1) the original work was penned in 1987, and due to the industry pervasiveness of many of the ideas presented by the authors, a lot of the material can no longer be considered extraordinary, and (2) the cohesiveness of each chapter and the flow from chapter to chapter is less than optimal - in other words, it is a bit choppy. Now I realize that there are untrained and/or inexperienced individuals in the software industry that can gain great strides in their respective workplaces by reading this book and understanding how best to apply the provided advice, which is why I give this work 4-stars rather than 3-stars, but I must say that I was just disappointed by all the hype about this book, from a year-2007 perspective. And simple math obviously will conclude that 20 years have passed since the original publication. The 8 new chapters added by the authors in 1999 really do not communicate many ground-shaking ideas. In my opinion, Chapter 33 is the only one of these new chapters that personally provided me any insight. And the premise of this lone chapter is simply that "the ultimate management sin is wasting people's time". The simplistic line graphs that accompany this chapter provide some substance to the discussion about project staffing, but again this chapter still seems to be geared toward individuals who do not bother to keep up with the insight shared in industry periodicals. Despite all of these drawbacks, however, there are some strong areas of the book that are worth reading by all software industry professionals. These strong areas are more comparable to the content of timeless classics like "The Mythical Man Month", "Death March", or "Waltzing with Bears" (see my reviews for all of these books), and are worth reading even if just to provide discussion starters within your organization. These chapters include "Vienna Waits for You" on working smarter and project deadline pressures, "Quality-if Time Permits" where the authors state that "Quality, far beyond that required by the end user, is a means to higher productivity", "Parkinson's Law Revisited" on estimations and productivity, "You Never Get Anything Done Around Here Between 9 and 5", "Brain Time Versus Body Time" on understanding the work day of a technology worker, "The Self-Healing System" on process, and "Teamicide" and "Open Kimono" on team jell. Realize that there are 34 chapters in this book. The bottom line is that this book on productive projects and teams, targeted at a software industry audience - although perhaps not overly impressive from a holistic perspective - is still heartily recommended.

Fortunately I found a company that already practices a lot of this, so the momentum against change is not high. If you're at a company that doesn't, their ideas do really work.

Peopleware: Productivity Projects and Teams [Tom DeMarco, Timothy Lister] was first published in 1987 - three decades later it is a revered classic. DeMarco and Lister focus on the human factor of software development (managing people). Through their 30 years of project management experience and consulting they share what went right, and more importantly, what went wrong - so we can learn from their mistakes.

This series of essays cover a wide variety of topics ranging from: office environments that encourage work, the importance of the closed door (read: "cubicles are BAD"), the significance of "flow" and creativity, the dangers and hidden cost of turnover, the importance of hiring and keeping the right people, how to retain employees, how to encourage productivity, the importance of a "jelled team", the dangers of teamicide, how not to manage people, and many other equally interesting topics.

Some quotes I found interesting:

"No one can really work much more than forty hours, at least not continually and with the level of intensity required for creative work." Chapter 3

"the process of improving productivity risks worsening turnover" (Chapter 3)

"People under time pressure don't work better; they just work faster." (Chapter 3)

"People who had ten years of experience did not outperform those with two years of experience." (Chapter 8)

"people who perform better tend to gravitate towards organizations that provide a better workplace." (Chapter 8)

"the total cost of replacing each person is the equivalent of four-and-a-half to five months of employee cost or about twenty percent of the cost of keeping that employee for two years on the job." (Chapter 16)

This book continues to change the way I view my job, organization, and career. Practitioners and authors like: Steve McConnell, Robert L. Glass, and Joel Spolsky heavily cite the industry-shattering truths originally exposed by Marco and Lister. This book should be on every professional's shelf along side other classics like: The Mythical Man-Month, and Code Complete.

Peopleware: Productivity Projects and Teams [Tom DeMarco, Timothy Lister] was first published in 1987 - three decades later it is a revered classic. DeMarco and Lister focus on the human factor of software development (managing people). Through their 30 years of project management experience and consulting they share what went right, and more importantly, what went wrong - so we can learn from their mistakes.

This series of essays cover a wide variety of topics ranging from: office environments that encourage work, the importance of the closed door (read: "cubicles are BAD"), the significance of "flow" and creativity, the dangers and hidden cost of turnover, the importance of hiring and keeping the right people, how to retain employees, how to encourage productivity, the importance of a "jelled team", the dangers of teamicide, how not to manage people, and many other equally interesting topics.

Some quotes I found interesting:

"No one can really work much more than forty hours, at least not continually and with the level of intensity required for creative work." Chapter 3

"the process of improving productivity risks worsening turnover" (Chapter 3)

"People under time pressure don't work better; they just work faster." (Chapter 3)

"People who had ten years of experience did not outperform those with two years of experience." (Chapter 8)

"people who perform better tend to gravitate towards organizations that provide a better workplace." (Chapter 8)

"the total cost of replacing each person is the equivalent of four-and-a-half to five months of employee cost or about twenty percent of the cost of keeping that employee for two years on the job." (Chapter 16)

This book continues to change the way I view my job, organization, and career. Practitioners and authors like: Steve McConnell, Robert L. Glass, and Joel Spolsky heavily cite the industry-shattering truths originally exposed by Marco and Lister. This book should be on every professional's shelf along side other classics like: The Mythical Man-Month, and Code Complete.

I think this book opens your mind in how to manage people as a book about SOA opens it in how to architecture an application. It gives no answers, but you will see how you would like to work after reading it.

Very impressive.

A must-read for managers especially, but useful for developers as well, who may be wondering why they don't enjoy their job as much as they would like. Clearly spells out the oft-hidden costs of development and why some teams work well and are enjoyable to be part of and why some are demotivating.

This book is relevant not just for software development, but for any team environment where the work entails thinking for a living.

I found this book a breathe of fresh air amongst the talk of productivity enhancements, out-sourcing and the latest must-use technologies.

A must-read for managers especially, but useful for developers as well, who may be wondering why they don't enjoy their job as much as they would like. Clearly spells out the oft-hidden costs of development and why some teams work well and are enjoyable to be part of and why some are demotivating.

This book is relevant not just for software development, but for any team environment where the work entails thinking for a living.

I found this book a breathe of fresh air amongst the talk of productivity enhancements, out-sourcing and the latest must-use technologies.

I would recommend anyone to read this book for project (task, mission) that is going to be carried out by a team or an organization. It is a humanistic (and not lazy) way of carrying out things. We all know that when the profession of management digress itself from keeping a close eye on human psychology, troubles are looming on the horizon.

Wonderful collection of thoughts and many gems. Hey.. does Amazon come with a six starts? :)

A very good book. You realize a lot of what has to change in your office after reading it. Most of the suggestions apply to office work in general, not just software development. Unfortunately most of the suggestions only apply to the ideal employees, who do actually take advantage of the improvements to increase productivity, which is not the case in most workplaces. Appart from that it is a must read for all who work in an office environment

A very good book. You realize a lot of what has to change in your office after reading it. Most of the suggestions apply to office work in general, not just software development. Unfortunately most of the suggestions only apply to the ideal employees, who do actually take advantage of the improvements to increase productivity, which is not the case in most workplaces. Appart from that it is a must read for all who work in an office environment

Tom Demarco in this book shows us what a great insight he has in terms of what are some of the key factors that can help as well as hinder software development teams/projects. Having worked as a software developer for 10+ years I can really relate to what Demarco says (unfortunately this is not always a good thing!).

This is a classic for team management. The authors try to dispel the technological illusion of team success and replace it with a much more mundane one - sociological factors. Through constant media barrage and our own efforts, we've created environments where management of 'knowledge workers' is far from optimal. Like any other job, as the authors point out, it is the ability of the workers to communicate with each other, rather than their abilities to communicate with the machines that create 'jelled' teams.

Many managers are willing to concede this pattern, very few manage that way. This is a must read for everyone managing, or aspiring to manage a team.

This book provides an excellent way of thinking about team environments for software development. While it doesn't have all the answers, it certainly asks a lot of good questions.

I read the first edition of this book about 10 years ago, and recently purchased and read this second edition. The book is a real eye-opener, exploding many myths about what it takes to make a team successful.

"Peopleware" is a classic work in its field, and is an easy read - not too long, clearly and engagingly written, relies on well-told anecdotes based on the author's own experiences, and is solidly packed with practical and useful advice. Tables, facts and charts supporting the book's themes are well presented, and the authors are careful to not go beyond what the facts support.

In the second edition, a sixth section, "Son of Peopleware", was added, consisting of 8 new chapters of material expanding on the original edition in light of what the authors have learned in the years since.

The central theme of this book is that teams are not machines, but are composed of people: the human element must always be considered, if not highly valued, to maximize not only your team's productivity and individual team-member job satisfaction (as well as your own), but to maximize your team's value to the organization as a whole. That the title starts with "Peopleware" is no mistake.

Anyone who manages teams in a business environment, regardless of the industry they are in, should read this book.

Hats off to Tom Demarco and Timothy Lister: great job!

I found in this book a really bright analysis for any organization. I like the approach, and I've found a lot of very useful tips for my proffesional life

Tom DeMarco writes classics about software development. Peopleware (1987 but updated version has since come out) is about people who develop software. It's about you. What people are like -- what works and what doesn't on topics such as working space, interruptions, how people work together in teams. What really goes on between 9 and 5, why, and what managers can help do to make it better. Don't expect coding theory in this one. Do expect common sense where DeMarco voices what people know but didn't say.

This book is full of information of things that current managers have forgotten. Every new project is wanted done with less money, less time and with higher quality than old projects, putting a lot of pressure to the project team. Managers do things that they believe is good for the project but actually damages the project (and the company) at long term. I have seen many co-workers leave my company for issues like the ones described in this book. Managers and company owners: Please read it!!!

This book takes a look at the role people, specifically creative people, play in a company. It offers various insights into management, the environment, and team "building". The second edition also adds a final section with eight new chapters with later insights.

While I agreed with much of what was written, there were some noticeable gaps such as mentoring, and business training (as opposed to technical training). Also, some of the content was, at this point, cliché (such as not treating people as widgets or, specifically, creative people as factory line workers, and the value of team "jelling").

Nonetheless, there is original content, and thoughtful suggestions, and the book is an enjoyable read.

First of all let me thank people responsible for making this book.

This book mainly talks about people, office environment, work environment, team etc. Eventhough, it is definite must read book for managers who manage software or software type of works(Application Specific Hardware, ASIC, VLSI, etc), it is highly recommended book for anyone from junior engineer to CEO.

Read this book to know,
- why somewhere today some projects are failing?
- why managers like to manage technology than people?
- how far do we need to push the quality of a product?
- how much space and facility should we need?
- what are the side effects of working overtime?
- what are the fundamental response to change?
and many more.

Excellent advise, best insight into the organizations, classic work area facts in simple plain English.

If you are a developer or a tester in a software project, this book will increase your productivity. I also believe it will make you appreciate or make you wonder the way your boss handles things... It's a must read.

Peopleware is a quick read that gets to the point. The point is; what is needed for a successful software development effort. Anyone familiar with software projects won't find any high level solutions.
We all know what is wrong with projects, we just don't know how to change them for the better. DeMarco and Lister give quick examples, statistics or suggestions on how to make those changes. For example, the myth that providing a window for all employees is to expensive is quickly shot down simply by comparing the price per square foot for office space in Denmark before and after the legislature required the everyone have their own window.
The writing is compelling. My QA manager quickly read the short chapter entitled "The Black Team". He now has made it a personal mission to tear into every piece of code submitted for testing as if the reputation of the company depended on it; which it does, which is the point.

To prevent becoming one of those clueless bosses, spend an afternoon or two and commit this book to memory. It's right for any office-based, technical business, not just software development.

Peopleware is a book that needs to be read by ALL people related to software development; not just managers and developers.

It has created plenty of debate between people in my company because of the 'saving on space' issue; also, some people from my company doesn't yet understand why a developer cannot be treated like a soldier (strict regime); this book helps out to understand such issues (and much more!).

Also it has been written in a pleasant and fast way to read. ýExcellent piece of work!

The remaining only issue:
It doesn't talk anything about the process of selling. Eventhough it's not a 'Sellingware' book, I think it deserves one chapter, just to create a link with the people that are in charge of generating money to support the 100 square feet that each programmer needs.

This a great book. You will learn without knowing you learned. Stop wasting time reading reviews. Buy the book and read it!

Get this book, and read it MANY times, over and over again.
If you are a developer, use it to put some ideas to your manager's brain. Try suggesting various ideas. Try lending it to him (I lost a copy of mine that way!)
If you are a development manager, try to turn as much as possible from what it says from theory into practice. It will only make everybody's lives much much more productive and happier.

Fantastic book about the people side of software development. The ideas in this book, and the typical corporate environment, are worlds apart.

My experience has been that managers either don't know this stuff, or if they do know it, then they feel that they would just have to go out on too much of a limb to implement these ideas. This is a shame because most for the concepts in this book are the very things that enable software developers to thrive.

One of the main ideas that resonated with me was the idea of giving developers enough private space. I have never been a fan of open plan office space. I think that it works well for some professions, but not all, and certainly not for software developers. Legend has it that Microsoft lets each developer have their own office which they can furnish as they please. One programmer is supposed to have brought in bucket-loads of sand to make his office into a beach !

If you are a Manager then read this book and implement as much as you can. Otherwise buy a copy and leave it on your Managers desk.

Lister and Demarco capture in this text the essence of why so many projects and initiatives fail across corporate landscapes - communication, planning, structure, and leadership. Most are lacking in today's fast-paced environments, whether driven by technology or not.

While the text has a bent for software development, the arguements and suggestions are valid across a wide number of management and project planning scenarios. Even if you're not able to implement their theories in your own organization, reading of the case studies and best practices can be therapeutic to see how "someone actually gets it." I have a photo-copy of one of the pages that addresses "burnout" on my cubicle wall. I often go back and re-read it to focus, breathe deeply, and plod along.

This book is HIGHLY recommended for personal reading, distribution to a team, or to your "management" at work. Very thought provoking and accessible.

In his 25th Anniversary Edition of "Mythical Man-Month", Fred Brooks points to PeopleWare as the influential IS book of the 1980's, and says that it was influential for the same reason MMM was: The primary challenges of software development are social, not technical. Companies that forget this are setting themselves up for failure.

If you've seen dilbert style software "management" and want to find a better way, I can't recommend this book more strongly. If you read it, you'll want to find a way to get your superiors to read it as well.

In my experience, a great deal of so-called "management" is really shoft-term optimization: "IF we can eliminate X benefit we can save $Y per year!" and cost control. DeMarco and Lister point out that the real goal is productivity, and suggest numerous ways to treat employees as people to get increased productivity, as opposed to treating them as inhuman "Resources" and managing by spreadsheet.

One story from the book: In my early years as a developer, I was privileged to work on a project managed by Sharon Weinberg, now president of the Codd and Date Consulting Group. She was a walking example of much of what I now think of as enlightened management. One snowy day, I dragged msyelf out of a sickbed to pull together our shaky system for a user demo. Sharon came in and found me propped up at a console. She disappeared and came back a few minutes later with a container of soup. After she'd poured it into me and buoued up my spirits, I asked her hwo she found time to for such things with all the management work she had to do. She game me her patented grin and said "Tim, this _IS_ management!" - TDM

This book is all about the manager's role: Not to make people work, but to make it possible for people to work. How to do that, how teams jell, etc. It's a pleasure to read and it's ... right. And in a field full of false promises, snake oil, and worthless statistics, that's saying something.

This book is well worth reading for both low level employees and managers. Although directed at the software development community, the book presents many ideas which would be useful in a wide range of companies.

It's amazing how many of the situations described in this book are familiar, or are at least situations that I could easily imagine occurring in the office work environment.

Yes, the book was written quite a while ago, but I think it's still very relevant today. Highly recommended reading, and enjoyable too. The authors really have a sense of humor.

This is a good book on software management; however, there are a couple of things to keep in mind. The references to the intercom paging system definitely date the book. I doubt this is really an issue anymore, but I am glad that it is not. Also, most companies are not going to allow the control over office space that is recommended in the book. This is where the book goes a little "pie in the sky" to me.

There is still a lot of good material for managers to consider. The authors make a very good point in the "true story" about the manager that brought soup in to an ill employee who was trying to meet a deadline. Management's job is to make it possible for people to work - not just to make them work.

I also found the information on teamwork to be very true based on my experience. I've seen defensive management at its worst, and how it was terrible to the team environment. Defensive management is a result of not following one of the earlier concepts of hiring the right people. Ultimately if you don't trust people to get the job done, why did you hire them in the first place?

Most of the information is not new nor is it really profound. However, that is the kind of thing that is usually taken for granted. The authors have given the material a good treatment and encourge the readers against this very thing.

This book is as essential as everyone here makes it out to be. However, the authors' development of the notion of teamicide needs to be seriously questioned. While there is some truth to their characterization of incentive-based systems or tracking through testing having the ability to go haywire, the stated anti-postulate reads like an articulation of the doctrine of the soviet. No individuals' performances can be acknowledged to the group? At all times it must be enforced that the only goal is the group goal? This is the only dark ray in an otherwise wonderful collection of great insights. The reality is that a balance must be struck. I know balance and shades of gray are not popular in our polarizing, cartoon times, but politically, both the extreme Horatio Alger and the notion of the great state have crashed and burned. Truly, what is needed are more plural forms of organization.

If you're working an environment you know is dysfunctional and could be better, Peopleware is definitely worth a read. This book is worth it just for the affirmation that how you instinctively know a knowledge business should work is, indeed, right on. If you're fighting petty battles against the Furniture Police, the book gives you good strategies for getting control of your cube back. Just a great and encouraging book all around.

The book was written about software development projects, but is absolutely loaded with insight not just on that subject, but on management styles and workplace conditions and rules. One can read this book and become genuinely excited about the potential explosion of productivity, hand-in-hand with employee job satisfaction, that could occur if managers would simply follow the advice given by the authors on how to be effective workplace leaders.

Alas, it probably won't ever happen. Several years ago, the large (Fortune 20) company I worked for brought in Timothy Lister to present the book and the ideas in it to management prior to the start of a major software project. Lister did an excellent job presenting his and DeMarco's philosophy. The managers nodded sagely and showed every sign of comprehending and accepting the concepts contained in the book. Then Lister left, the project started, and the managers immediately reverted to the old style: setting unrealistic deadlines, pressuring employees to deliver more and more in less and less time, and in general following every tired old management strategy that almost always leads to a failed project -- as indeed, it did in this case.

So read this book, learn from it, and enjoy it (it's an easy, entertaining read) -- even if your managers are too stupid to profit from it.

The main goal of this book is that it encourages the software developers and their management to think deeply about they way they create the software. Software development is the "research", not the "production", and the stimulus and processes that work well in for example metallurgy will harm software development. The authors show the consequences of borrowing organizational processes from other areas to software. They encourage to focus on the people rather than to process. The software developers aren't "replaceable units", "plastic uniformed people".

Although the textual work of the authors is marvelous, the quality of the printed book (paperback edition) is awful. The paper is thin and translucent, showing the lines from the other pages, the interline spacing is too low, turning a page to a big mess. That was the only reason I've rated the book as four-stars.

The information in this book is very accurate, without pure assertions. The authors always are giving full references if they are providing figures or studies. The authors have a good sense of humor, and it is the great pleasure to read this book. The information is given in the very dense manner: the other authors might have needed ten volumes to express what Tom DeMarco and Timothy Lister has put in this small book.

I strongly recommend this book to any individual involved in software development, as well as "Agile Software Development" by Alistair Cockburn. These books aren't from "ten steps to success" series. They encourage deep, creative approach to the topic.

This book was recommended to me by the finest manager I've ever had the pleasure of working for. After reading it, I realized what set him apart was that he applied the principals described by DeMarco and Lister and what a difference it made! After reading it, I bought two more copies, one for my current boss and one for another developer. Both were heard singing its praises to their bosses. The book is good enough that it they either bought it for their bosses or handed their own copy to them. You can't get a much better recommendation than that.

That is, if you have an interest in any aspect of software development, project management, or just plain management.

Although the book is getting a little long in the tooth, the advice and observations, based on the authors' decades of experience consulting to the software industry is spot-on and insightful.

The price put me off buying it for several months, but I was very glad that I finally invested. The book is full of common sense that somehow isn't so common, and the authors point out many of the more common mis-assumptions that cause projects (and teams) to fail.

The central thesis is that most projects fail because of mishandling of the people aspects of the project team, rather than problems with the technology. Project managers who take the advice provided to heart will stand a much better chance of achieving the successful results they need.

Reading the table of contents for Peopleware tells you a lot about the content and the tone. Here are a few of the chapter headings:

Quality - If Time Permits
"You Never Get Anything Done Around Here Between 9 and 5"
The Whole Is Greater Than The Sum Of Its Parts
For two decades, Tom Demarco has been writing in plain, narrative English about improving IT project team productivity. In this book, he describes some of the reasons for our failures, reasons most of us know about - but rarely do anything about.

Pick a chapter. Let's say "Bring Back the Door". Some of us remember the days when we worked in an office with a door, the days when it was taken for granted that engineers needed a quiet, low-distraction environment to focus on their work. Alas, those days are gone and the cubicle farm has become so noisy and distracting that many people find they can be the most productive only when no one else is around. As DeMarco says: "As long as workers are crowded into noisy, sterile, disruptive space, it's not worth improving anything but the workplace."

The best part of this book is in Part IV - Growing Productive Teams. The agricultural analogy is purposeful - "growing" productive teams takes time, care and feeding. One of the harmful "Teamicides" DeMarco discusses is the fragmentation of time, the requirement that most engineers work on multiple projects at the same time. If management wants to get the productivity that is derived from 'jelled teams', they have to know that "no one can be a part of multiple jelled teams", he says.

The book is a fast, easy read. The prescriptions for achieving greater team productivity aren't fast or easy. But you have to start somewhere. To start, read this book.

As a long time software development manager, this book validates the common sense I knew I had. That common sense approach to developers will never come from text book management. I wish I could rate this book a 10.

If you're a software manager, and you haven't read "Peopleware," stop reading this, and go read that instead. It's that's good. If you're a developer or engineer on a team that's not getting anything done, read it. This book is filled with practical advice on teams, team building, and getting work done.

"Peopleware" doesn't go in for theory. It puts into words what any contemplative manager already knows intuitively. The benefit of this book, however, is that it provides concise, powerful evidence to support each of its statements on team building and managing creative people. "Peopleware" covers it all -- why you have high turnover, why you have low productivity, and how to get your team to "jell."

The design of the book is excellent. There are 34 chapters in 226 pages. The cover struck me as funny on such a thin book: "Eight all new chapters." How did they fit all that into such a thin book? Simple: each chapter is very focused and short -- an entire chapter on a concept can be read in a single sitting -- even by the busiest manager. I recommend you read a chapter first thing in the morning, keep the ideas in your mind all day, and then read that chapter again in the evening. It will help you get the most out of what the book has to offer.

Part one focuses on managing people. It describes how development is different from manufacturing, what motivates people, and some of the pitfalls. It also focuses on you, the manager, and your role in the success of your project. Part 2 zeros in on environment. DeMarco and Lister single out environment as one of the biggest sources of problems in development. As such, they devote more time to this than any other subject in the book. It can get a bit repetitive, but the points they make are important, so it is easy to forgive them for focusing on it so much.

Parts 3, 4, and 5 address people, teams, and work methods. These areas may be of the most immediate value to a beleaguered manager, as it is here that they have the most opportunity to make changes, and where they typically have the least training. The authors focus on how to work with individuals, move on to making teams "jell," and finally on how to make work more meaningful and dynamic to reduce turnover, which "Peopleware" labels as "a cancer."

Finally, part 6 is the new stuff added to the second edition. As a result, they are a set of unrelated essays, not integrated with the rest of the text. However, they are quite a bit more timely than the earlier chapters, which sometimes feel a bit dated. It would have been nice to see these chapters more integrated with the rest of the book, but that's a minor quibble. The section on Process Improvement Programs (such as CMM) is very insightful, and will strike a chord with many people who question the value of the implementation of these programs in their organizations.

"Peopleware" is simply the best management book I have read for the front line technical manager in a development organization. It is a complete course from the school of hard knocks on what works and what doesn't in the real world.

I bought this book because is one of the most cited references in Steve McConnell's Rapid Development and also because people factors are, as McConnell points out, the most infuencing factors over productivity on any software development project. DeMarco and Lister have recorded their experience in people management issues in a surprising thin book, each part and chapter follow a well laid sequence of steps that are focused on specific issues and, in parallel, the book is full of useful data extracted from studies.

This combined with a pleasant writting style has produced a book easy to read (I read it on a weekend) that has make me think a lot about many things that people with responsability over other people must keep in view at all times. It was nice to view my professional experience on the matter reflected on its pages. I think that is a book that must be read by the entire chain of command in every company that wish to make software development profitable.

If you are or want to be a manager this book is doubtlessly for you even if your company or field of expertise is not the software development.