Scroll down
The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work in the field, for folks like us who write books, it is positively tragic.
Peopleware : Productive Projects and Teams, 2nd Ed. by Tom Demarco, Timothy R. Lister
ISBN: 0932633439 This book is available from Amazon
The more you improve the way you go about your work, the harder the work will be.
The projects most worth doing are the ones that will move you down one full level on your process scale.
Quality is free, but only to those who are willing to pay heavily for it.
The manager's function is not to make people work, it is to make it possible for people to work.
The last project generated a ton of paper and it was still a disaster, so this project will have to generate two tons.
First law of Bad Management: If something isn't working, do more of it.
Companies that downsize are frankly admitting that their upper management has blown it.
If the date is missed, the schedule was wrong. It doesn't matter why the date was missed. The purpose of the schedule was planning, not goal-setting.
A day lost at the beginning of a project hurts just as much as a day lost at the end.
Process obsession is the problem. Process obsession is not just an anomaly that occurs now and again. It is an epidemic.
The danger of standard process is that people will miss chances to take important shortcuts.
I see design standards that don't tell you how to come up with a good design (only how to write it down), employee evaluation standards that don't help you build meaningful long-term relationships with staff, testing standards that don't tell you how to invent a test that is worth running.
Slack
The ultimate management sin is wasting people's time.
The major problems of our work are not so much technological as sociological in nature.
We all tend to tie our self-esteem strongly to the quality of the product we produce - not the quantity of the product, but the quality.
Since the days when computers first came into common use, there must have been tens of thousands of accounts receivable programs written. There are probably a dozen or more accounts receivable projects underway as you read these words. And somewhere today, one of them is failing. Imagine that! A project requiring no real technical innovation is going down the tubes. Accounts receivable is a wheel that's been reinvented so often that many veteran developers could stumble through such projects with their eyes closed. Yet these efforts sometimes still manage to fail.
The documentary obsession of Methodologies seems to have resulted from paranoid defensive thinking along these lines: 'The last project generated a ton of paper and it was still a disaster, so this project will have to generate two tons.' The technological sectors of our economy have now been through a decade-long flirtation with the idea that more and more and more paperwork will solve its problems. Perhaps it's time to introduce this contrary and heretical notion: Voluminous documentation is part of the problem, not part of the solution.
There are a million ways to lose a work day, but not even a single way to get one back.
During the past year, I did some consulting for a project that was proceeding so smoothly that the project manager knew she would deliver the product on schedule. She was summoned in front of the management committee and asked for a progress report. She said she could guarantee that her product would be ready by the deadline of March 1, exactly on time according to the original estimate. The upper managers chewed over that piece of unexpected good news and then called her in again the next day. Since she was on time for March 1, they explained, the deadline had been moved up to January 15.
