Software Engineering discussion

After several deep technical books, I am enjoying the breezier, shorter, Peopleware selection! It has echoes of the "Mythical Man Month" book.

I think that we need to keep the timeframe of this book in mind when reading it. The first edition came out in 1987, and the second edition in 1999. These were boom periods for software engineering, when demand outstripped supply and focus on retention outweighed focus on downsizing. I wonder if the interest in people issues in software, and interest in this book, wanes during recessionary periods? Also, the book highlights HP, especially their product quality. I am not sure that I would conclude that today. The book "In Search of Excellence" and others like it show that corporate greatness tends not to last.

There is no question that attention to the people issues in software engineering is important, and often overshadowed by the technical and project management issues. I also agree that since managers are often selected for their technical ability, and not their people management ability, software development managers need to make an extra effort to pay attention to these issues.

I am not persuaded by all of the arguments in this section. In particular, it might be true that software engineers produce better products when they decide that the products are ready, and not forced to a manager's schedule. However, in my experience, most software is never done. There is always room for more testing, more refactoring, more polishing. One of the key roles of a manager is to provide a end date for a process with no natural end. For large projects, no defined end date for one programmer means no defined start date for the programmer who depends on their code, and that is chaos. I do agree with the final message that an expert 3rd party might provide the best estimates, compensating for the manager's natural tendency to force schedules on programmers, and the programmer's natural tendency for over optimism.

I never heard of the Spanish Theory of Value before, and the book's discussion on that mindset, and the impact on overtime management, was enlightening. I think that this is the referenced theory, but I am not sure of it.

http://en.wikipedia.org/wiki/School_o...

The best line in this section is the last one:

"The manager's function is not to make people work, but to make it possible for people to work."

I didn’t expect this book to be as interesting as it is. Not my favorite subject, but definitely important one. Pretty much everything in Part I sounds good to me most probably because I’m not a manager, especially “bad” manager who forces people to work overtime, put them under pressure, trying to automate engineering process, and has no soup for sick engineers. Jokes aside, I really enjoyed reading it. I can’t agree more that most managers seem to have more technical and business development than business administration and management skills. Though I’ve met managers who I thought were really good at what they do. My favorite chapter is Quality – If Time Permits. Self motivation must be one of the greatest skills in today’s working environment that "helps to deal” with business goals. I didn’t like the example about manager with a soup, not a big fan of this kind of "management", though the conclusion worth it.

As a software developer, it is nice to read many of these points and realize that they don't apply where I work; apparently those complaints have already been addressed. But that (along with how long this book has been published and therefore how long they've gone "unfixed") makes me wonder about the situations that are still as described. Why haven't they been fixed? Is the book is wrong about them?
For instance, take schedules and estimates. In short the authors say that schedules shouldn't be used, and that the project should ship when it's finished. I understand why they're saying that: using schedules to bully employees into overtime, working faster, or dropping quality is not productive. But estimates are also used to determine the value of a project. A feature may be worth doing if it will take three man-months to implement, but not if it will take six. And schedules have uses too. Besides hitting market windows (which probably aren't as important as they are touted to be, unless your trying to hit a holiday season or some other large event), schedules are used to determine how to time other activities, like advertising, that need to be timed with delivery.
Others, particularly the propensity for production management techniques to find their way into development, seem to be staying around because they are just too tempting to walk away from. When a hammer works so well on a nail, and a screw looks so much like a nail at first glance, it's just too tempting to try to use the hammer on a screw... and it even seems to work at first.