Slashdot Mirror
Slack
Summary: A highly entertaining, and informative survey of the state of the high-tech and software industries today, which suggests that companies have been taking exactly the wrong actions under pressure and further decreasing their ability to handle rapid change. The book is peppered with interesting asides and examples, but is always informed by the central thesis that companies need more Slack built back into their structures.
Check your sources. Tom DeMarco is an established industry management guru who has the respect of many of the technical community. He's written several previous titles, including the notable Peopleware and the collection, Why does software cost so much?. I'm not normally keen on any books in this genre, but have always found DeMarco's writing very readable and though-provoking -- most importantly for me, he has a habit of trying to find NUMBERS to back up any claims.
What's this book about? This is a 2001 title, and I find it slightly shocking that, in a maturing industry, we still need a book on this topic (from the blurb):
"To most companies, efficiency means profits and growth. But what if your 'efficient' company - the one with the reduced headcount and the 'stretch' goals -- is actually slowing down and losing money? What if your employees are burning out doing the work of two or more people, leaving them no time for planning, prioritizing, or even lunch? What if your super-efficient company is suddenly falling behind?"
So far we're just talking about the state of the modern software industry right? What's he proposing we do about it?
"[...] what you need is not more efficiency, but more slack. What is 'slack'? Slack is the degree of freedom in a company that allows it to change."
It seems a very simple concept to me, but then I'm an engineer, his writing is persuasive, and I have the benefit of 20-20 hindsight when reading. How can he get a 220 page book out of such a simple concept? After all, all we programmers know that your general purpose solutions always sacrifice speed for flexibility right?
What he discusses is a business model where you keep people, say, 70% busy. This leaves time for unexpected business, for reflection on why X takes so long and how to fix it, for self-training, for discussion about how things are done. These are all good things -- but the winner is that when people are stressed by sudden change or a deluge of new work, they have some slack to take in. Things change, you suffer a reduction in productivity, but hey, you had some slack to take in so the week's work is still getting done, you've just dropped that Ruby book for a week or two. You're swamped by a rush on finishing Product X before a competitors Product hits the market first -- just drop that tinkering with a novel memory pooling thingy you were considering slotting in to replace the adequate-but-inelegant solution in your product. I'm simplifying and reducing his argument here, but that's the idea. The other corollary to the 70% busyness level is that the system is responsive -- some nodes are 100%, some are 20%, but overall things are flowing. A system where most nodes are at 100% means some nodes are hanging waiting for other nodes to catch up -- total throughput drops. This'll make more sense reading his version ('underworked but responsive secretary' vs '100% busy, cannot help until Friday secretary'), but it's a good central topic -- simple, but not trivial.
220 pages isn't much -- he states that the book should be comfortable reading for a business trip -- and the bulk of the space is taken up by rationale for his suggestion, and discussion of the consequences. What I found valuable about the book was the description and subsequent debunking of several management techniques -- for example, he has a severe go at management-by-objective. I recognise it. I suspect you too will recognise it, and several other common variations.
Let's have a quick skim of the contents -- this isn't a technical book, more one massive opinion column, so the section titles aren't that useful, but I feel like I'm cheating if I don't do this in a review ...
- Slack
Madmen in the halls, busyness vs business, the myth of fungible resources. This section sets up the case by setting out the assumptions, and describing what actually happened to most businesses when put under pressure in the last 10 years. I loved the word "fungible" too -- describes a resource that can be freely interchanged -- like paperclips are and software designers aren't. - Lost, but making good time
The cost of pressure, aggressive schedules, overtime, culture of fear, quality, management by objective. This is a meaty section and basically describes how the heck things got to be this way, what practices were adopted, and how they made things worse... - Change and growth
Vision, leadership, fear and safety, trust, what middle management is there for, change management. This section talks about change, specially why a lot of the measures adopted to prepare for it help make things worse, and how we should instead consider other approaches. - Risk and risk management
Working at breakneck speed, learning to live with risk. This seems like a short section from the contents, but it's reasonably long. There's less to discuss here for what we have is a 2-by-4 to head of businesses who refuse to plan for failure. A discussion then follows of the classic problem -- scheduling -- and why you'll never do a decent job of that without risk management. This is the only section where the tone is hectoring rather than persuasive -- or else that was my own frustration at the experiences I've had coming into play!
Target audience It's aimed at a particular segment according to the cover: "A handbook for managers, entrepreneurs, and CEOs." Well, I'm none of those, but I enjoyed it and found it useful. I'd prefer that my bosses were reading this than most of the other pap from the same shelf, but let's face it, change comes from all levels in the organisation, and if you can't spot mistakes being made within your team then you can't plan for your own career either. Read this book, it'll come in useful either when your managers start going awry and making you suffer, or it'll come in useful when you float up the org chart and have to start dealing with a team of your own.
What's good? Most of it. This is a highly entertaining read, and does present some genuinely useful ideas. It's also great as a collection of management anti-patterns. I think any career programmer in a medium-sized or above business would find this book interesting. Actually, come to that, anyone who enjoys Dilbert will enjoy this book.
What's bad? Not much. There were a couple of areas where I would have liked more case studies or evidence. As I said above, the recourse to surveys for the truth is something of a trademark of DeMarco -- he certainly references quite a lot of material in this book, but doesn't produce any solid evidence to back his ideas. Granted, probably hard to experiment on this scale!
You can purchase Slack from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
bn.com has the book listed for $18.40. Amazon has it for $16.10.
Save yourself some money.
Hmmm, I thought the true way to obtain Slack was through Bob Dobbs.
As usual, this book is a couple of bucks less at Amazon, or even more than a couple if you don't mind a used copy.
And moderators, this isn't redundant. A lot of people actually think Slashdot links the cheapest site.
"If you think education is expensive, try ignorance" - Derek Bok
Support the Tattered Cover who supported our free speech.
ACLU on Tattered Cover Decision
Free Expression.Com on the tattered cover case
Interview with Tattered Cover's owner.
This fantastic book is $14.00 at an independent bookstore who values freedom. If you remember, about one year ago there was a big case in Colorado where the Tattered Cover bookstore refused to give up records of customers who purchased particular books to the authorities on grounds of free speech. This is detailed here,here, and here. Big chains like BN and Amazon don't take stands like this.
I picked up this book for about $10 at a super-mega-uber-discount bookstore in San Francisco earlier on this year. Boy, what a bargain.
This book absofuckinglutely rocks. After I was about 50 pages into it, I started evangelizing it to all my game programmer and IT friends. I wish that every manager and project manager would read this book. There are some amazing ideas and concepts in that book that are no big surprise, but you'd think that these concepts would be impossibilities looking at how people manage!
There are some "amazing" ideas like: (paraphrased)
* 'If a project fails to meet a deadline, it's not the fault of the employees doing the work, it was the responsibility of the project manager to make a realistic project plan'
* 'No matter how many hours you force your knowledge employees to work, they'll still only be as productive as they would have been in 8 hours of work.'
* 'Interrupt your knowledge workers often, and it reduces their productivity'
* '100% efficient means no flexibility'
* 'Constant meetings make managers not able to manage'
* 'It costs money and time ($$$) to train a new person, so keep your old people happy if they're doing their jobs.'
The scenarios presented in this book rang so very true with the dotcom paradigm and the game industry. I couldn't believe how well everything applied. That whole book should be applied.
Most of these ideas aren't big surprises, but damned if people don't listen. I reiterate: I wish that every manager of knowledge workers would read this book, and that members of upper management would take time off from their busy meeting schedules and read it too. I think that it could make some kind of difference and even a tiny one would be amazing.
Us dotcommers burned out and used that severance period to get our lives back, but a good number of companies are still behaving like they did back then, and currently employed people are burnt out and/or burning out.
As someone who was an IT manager and still intends to be an IT manager, it was an excellent read. I just wish that my manager and the the COO would have read that damn book.
Burnt out employees is a bad thing. This book in the hands of managers is a very good thing.
I have a car capable of going 143 miles per hour. However, I have only driven it that fast once, and most times I hover around 70 mph. The car is designed to perform for a long time when well maintained and driven at sane speeds. The same can be said for people. An employee can work 80 hours a week as fast as they can, but it is the equivalent of driving a car too damn fast for too damn long. On an average work day, I work at 70%. It's not that the other 30 percent is wasted, it is just extremely flexible. I'm currently using my extra 30% to refactor some stuff, read some good programing books, look at new technology and what not... all stuff I can drop at a moments notice so I can devote that extra 30% to something else.
Using the 30% as I want keeps me interesting and happy.
The false perception is that the 30% is lost. It is not.