Two outstanding books in this area are Fred Brooks, The Mythical Man-Month and Peopleware by DeMarco and Lister.
Here is a short essay on some things to keep in mind during software development.
John C. Thomas
T. J. Watson Research Center
PO Box 704
Yorktown Heights, New York 10598
Abstract: Incredible advances in processor power, memory size and speed, bandwidth, and peripherals, as well as advances in software architecture have helped fuel a revolution in knowledge management. Yet, in many organizations today, the "knowledge management" problems that remain unsolved are not remaining unsolved for lack of sophisticated technology. They remain unsolved because people seem to have forgotten, never learned, or systematically ignored some fairly basic and simple principles. The list of such principles offered below is not meant to be exhaustive or profound. They all seem obvious; they are relatively straightforward to implement; and yet, they are often breached.
1. Render to Computer those things that computer does well and those things to Human that Human does well. This principle was articulated by an IBMer, R. B. Miller as early as the 1960's. Once stated, it seems rather obvious. Since Miller's time, the capacity of the computer has expanded enormously while human abilities have remained fairly constant. People are superb at perceptual-motor activity, social interactions, and natural language processing. Although technology has progressed in all these areas, final judgments in these areas are best made by people, if quality matters over expense. People are not particularly good at remembering or transmitting arbitrary codes. And, yet, we interact with systems on a daily basis in which we human beings are supposed to be remembering such arbitrary codes, looking them up, and transcribing them. The human capacity to learn arbitrary codes is only 1 chunk (approximately and address) every four seconds. The capacity of people to transmit such codes is only about 3 bits/second. This is not an effective use of the human brain.
2. Provide people with Feedback -- often and well-structured. Humans are remarkable in their capacity to learn complex motor, social, and cognitive skills. Yet, in order for learning to take place, the human being must have an opportunity to see the results of their actions. Feedback should be given as soon as possible. Since there is often an emotional component to feedback, it is typically more effective to give positive feedback before negative feedback. If there are suggestions for improvement, it is best to see whether the person themselves can make such suggestions.
Yet, we see many knowledge systems operate in which people gain minimal feedback from their performance. To take just one rather obvious and ubiquitous example, designers and developers often hear nothing from help desk personnel or trainers about the confusions their products induce in users. Similarly, many designers and developers never have the opportunity to observe real users in their real context using their products. Under such circumstances, how can learning take place?
3. Use Processes designed for the Goal you have. Many specific processes have been developed for groups to work together effectively. Many managers in organizations, however, attempt to invoke the power of a process by merely using a term like "brainstorming" or "dialogue" without any understanding of the process, without doing the preparation necessary to use such processes, and even without knowing the circumstances under which various processes are useful.
4. Make sure a Human Being (or small Team) is responsible end to end. Make sure people understand the context of their work. If processes are broken into pieces and people only have a limited view, they will not operate effectively. Reported in Think magazine some decades ago was the story of a woman who worked on an assembly line for IBM. One day she went to a class that showed workers the overall process that went on in the factory. She reportedly jumped up in class and screamed, "Oh, no! I've been doing it wrong all these years!" Once she calmed down, the story came out that she had been inspecting masks. Since she knew that IBM put a lot of effort into making the masks (but had not understood what they were for), she felt she was saving the company money by letting masks go that only had one or two errors in them. Every handoff is an opportunity to drop the ball!
5. Begin every design process with understanding the context, the users, and the tasks. Iterate. It has been shown over and over that failure to do so results in products and services that are error-prone and disliked. In The Trouble with Computers, Tom Landauer documents that IT projects that do not take this approach improve productivity an average of 1-2% year over year, while those that do take this approach improve productivity an average of 30%/annum. As Fred Brooks said, "you will build a prototype; the only question is whether you will sell it to your customers as a product."
6. Design systems to allow expressive communication. No matter how well-designed, every product, service, and process needs to allow human annotation and exception handling. In addition, when people use expressive communication they learn more about each other and may develop trust.
7. People are energy processors as well as information processors. The manner in which information is delivered makes a difference. Seeing "Gone With the Wind" and reading a synopsis which gives "the bottom line" are not the same. Seeing the actual painting, Guernica, and seeing a 5 cm. by 5 cm. reproduction are not the same.
You may also want to check out the Software Engineering Institute at http://www.sei.cmu.edu/
The IEEE Computer Society at: http://www.computer.org
And, certainly, ACM's Special Interest Group in Software Engineering at: