Visual supervision is a joke for development workers. Visual supervision is for prisoners.

The Gist

Peopleware, originally published in 1987, is the most relevant book ever written for managing software teams and organizations. DeMarco and Lister give a light-hearted take on all the wrong ways to manage IT projects and give helpful shoves towards some better alternatives.

My Opinion

I knew this book would be a good fit for me, but I had no idea just how much I would like it. This book connects a lot of pain points I’ve had so far in my (relatively) short career, so much so that I cannot believe we still have these problems nearly thirty years since its inception.

In particular, I found the first half of this book life-affirming. The second half is more about managing people/teams, which is harder for me to get a grasp on as a developer, though now I’ll be quietly (or loudly) judging my managers based on what I read. Let me go into details about all my favorite parts of this book.

Quality – If Time Permits. Sacrificing quality for the sake of time and/or money is an extremely common theme in our industry. Not only does a low-quality product hurt the bottom line, but software builders base thier self-esteem on the quality of their code and releasing bad code makes us feel bad. Morale is guaranteed to hit rock-bottom when we are not given enough time to determine edge cases and iron out bugs before releasing a product.

Parkinson’s Law is complete gibberish. Parkinson’s Law states that work expands to fill the time allocated. I’ve heard this phrase thrown around pretty persistently in my professional life, especially when we talk about estimating story points. I shouldn’t need to go into why this is a terrible thing to tell a dev team. It’s insulting; do we truly believe that our development team does not want to get the work done as efficiently as possible?

The Office Environment. This part of the book hit a little too close to home for me. I recently moved desks and have been having unforeseen interruption and distraction issues. I sat right next to the door entering Main Engineering. Hundreds of times a day, I would hear the beep! of a badge swipe, the clunk! of the door unlocking, the crunch! of the handle being pushed in while the door swings open, and finally the ker-chunk! of the door closing and locking. Each of these times, my head would naturally bounce up towards the doorway to see who’s entered. In the most unfortunate of cases, I would make eye contact with the intruder, prompting them to come and chat for a brief moment. Time and time again, my concentration would be broken. I finally realized this a few days ago and moved my desk back into a little corner, which alleviated a big part of this problem.

You Never Get Anything Done Around Here Between 9 and 5. I have become somewhat infamous in the office for being the first one to work. I currently arrive around 7am, although I’ve been known to show up anywhere between 5:30am and 7:30am depending on what I’m working on. I do this because the open office plan that software culture is currently infatuated with drives me insane. I had begun to think I was the only one in the industry who would prefer a shared private office to an open cube farm, but fortunately this book has reassured me of my sanity. Knowledge work requires quiet time without distractions or interruptions, which often means it requires walls and a door.

You Never… also discusses space issues. The authors are famous for conducting “coding war games,” where individuals from different companies compete in a programming challenge while timing themselves and writing down every disruption that affected their time. In these studies, they found that those with a greater amount of personal space tended to do better than those with less. The top quartile had 78 square feet on average, while the bottom had 46 square feet. My estimate puts my current space at around 40 square feet.

Somewhere in The Office Environment, the authors discuss windows (the transparent kind), which I wanted to breifly touch on. Our current facilities are window-rich, but window-seat poor due to the design of the building. Fortunately, we have a Commons area that is “Oops! All Windows” at our disposal, but I would love to be able to glance out a window from my desk. My eyes get tired throughout the long day of staring at my computer; the authors prescribe desks with at least 8 feet of space between the developer and the wall such that the developer can let his or her eyes rest from time to time. This is a difficult problem to solve with cubicles. Windows also help with this.

There is also a lot of content in this book about managing people, especially those in software. You should read it. There are good discussions about not forcing teams to do overtime, keeping players who work well together on the same teams, and letting underlings make decisions.

All in all, this book was incredibly useful for me and made me feel a little less alien. I read the second edition of this book, though I have come to learn there has recently been a third edition released.

Who Would Like This

Software developers and anyone who thinks they have direct control over software developers should stop whatever they are doing right now and read this book. Did you read this book twenty years ago? Read it again.