This set of reviews is on two classic tomes that have been on my to-read list for some time.
Peopleware: Productive Projects and Teams
This book is written from the perspective of advising a manager of software developers, but certainly should be read by ANYONE working in software development. The basic premise is that a typical office environment, traditional management styles, and culture of overtime in our industry decrease developer productivity. It contains many insights which a single person could only piece together after an entire career of working on development teams. Take advantage of other's experience!
Following are some of my highlights:
The structure of a team is a network, not a hierarchy. For all the deference paid to the concept of leadership (a cult word in our industry), it just doesn’t have much place here.
Open plan workspace? Think again.
"The bald fact is that many companies provide developers with a workplace that is so crowded, noisy, and interruptive as to fill their days with frustration."
"An hour in flow really accomplishes something, but 10 six-minute work periods sandwiched between 11 interruptions won’t accomplish anything."
Most non-developers do not realize that software development is actually a creative discipline that requires deep focus.
"Nobody can really work much more than forty hours, at least not continually and with the level of intensity required for creative intellectual work."
"If you are charged with getting a task done, what proportion of your time ought to be dedicated to actually doing the task? Not 100 percent. There ought to be some provision for brainstorming, investigating new methods, figuring out how to avoid doing some of the subtasks, reading, training, and just goofing off."
Good developers thrive on autonomy and trust.
The mark of the best manager is an ability to single out the few key spirits who have the proper mix of perspective and maturity and then turn them loose.
People who feel untrusted have little inclination to bond together into a cooperative team.
The Mythical Man-Month: Essays on Software Engineering
This book is also related to team productivity and success but focuses more on project failure caused by scheduling mishaps. It gives a sort-of lessons-learned from the experience of managing the development of the OS/360 operating system. I think it is especially important for project managers in the software industry to read to understand how traditional methods do not work when it comes to development.
Following are some of my highlights:
Hardly any projects succeed in less than 3/4 of the calculated optimum schedule, regardless of the number of people applied!
One point that really resonated with me is the idea of "conceptual integrity", having experienced the chaos that ensues when many people are allowed to introduce different ideas into one codebase and everyone is too timid to refactor something they didn't write.
"I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas."
"Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds."
Scheduling is often done assuming all developers are strictly coding and for long hours.
- "...teams were only realizing 50 percent of the working week as actual programming and debugging time. Machine downtime, higher-priority short unrelated jobs, meetings, paperwork, company business, sickness, personal time, etc. accounted for the rest. In short, the estimates made an unrealistic assumption about the number of technical work hours per man-year."
Adding people does not help the schedule in the short-term. "Communication effort" increases, and the inevitable communication breakdown that occurs as people increase causes introduction of competing or redundant ideas into the system (bugs).
"Since software construction is inherently a systems effort—an exercise in complex interrelationships—communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men then lengthens, not shortens, the schedule."
"When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule."
And early praise for iterative development (this book was first published in 1975).
"I would go a step further and assert that it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying."
"Much of present-day software acquisition procedures rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy."