Prior to reading The Psychology of Computer Programming by Gerald Weinberg I only thought about a small part of the human side of software development. The book deals with subjects that are rarely discussed or addressed:
- Personality traits
- Leaders and leadership
- Physical environments
- Social organization and common social problems
- How a team forms
- Formal and informal structures at work in teams
- Motivation
- Training
- Forces against learning
As usual, Gerald Weinberg tells some great stories although this book was a little hard to get through since it read mostly like a text book. It was a bit dated but it contained some great anecdotes and timeless themes.
The book's main point is thinking about computer programming as a human activity and programmers as a human beings, rather than machines. The benefit would be programmers functioning more efficiently and with greater satisfaction.
The book discusses why the human side is overlooked:
Computer programming is a human activity. One could hardly dispute this assertion, and yet, perhaps because of the emphasis placed on the machine aspects of programming, many people - many programmers - have never considered programming in this light. Among programmers, there is a certain mystique - a certain waiving of the hands which takes place whenever one tries to probe the manner in which programming is done. Programming is not done in a certain way, they say, it is just done. Either you can program or cannot. Some have it; some don't.
Some food for thought:
Writing a program is a process of learning - both for the programmer and the person who commissions the program. Moreover, this learning takes place in the context of a particular machine, a particular programming language, a particular programmer or programming team in a particular working environment, and a particular set of historical events that determine not just the form of the code but also what the code does!
In a way, the most important reason for studying the process by which programs are written by people is not to make the programs more efficient, more compact, cheaper, or more easily understood. Instead, the most important gain is the prospect of getting from our programs what we really want - rather than just whatever we can manage to produce in our fumbling, bumbling way.
There are many reasons why programs are built the way they are, although we may fail to recognize the multiplicity of reasons because we usually look at code from the outside rather than by reading it. When we do read code, we find that some of it gets written because of machine limitations, some because of historical accidents, and some because of specifications - both essential an inessential. But for whatever reason a particular piece of code gets inserted into the final product, there are psychological aspects to that reason.
Putting a bunch of people to work on the same problem doesn't make them a team.
Each person working on a team within a project has come to accept certain of the team goals as his own. But when the team is specialized, its goals do not necessarily coincide with the overall goals of the project, or with the goals of another team. These conflicts are invariably manifest is some sort of social relations.
The job of getting from specifications to delivered program demands various kinds of work, which in turn, demand various talents...it may be that suitability for work in one stage of programming makes one more or less unsuited for work in another.
Personality affects programming performance.
If we are to ensure that the proper talents are available when needed, we shall have to classify the work that programmers do into somewhat more refined categories than the simple term "programming" covers.
An interesting topic was egoless programming or the ability to realize human limitations and the restructuring of the values system of programmers. Programmers should look for and welcome criticism, and realize that we all have bad days or days where we are just not going to produce anything of value.
I really liked the section that discussed documentation:
The value of documentation is only to be realized if the documentation is well done. If it is poorly done, it will be worse than no documentation at all.
There is no way to force programmers to produce good documentation...The only hope for producing good documentation is to convince the programmer that is will benefit him to do so. If the act of producing the document has demonstrable good effects, there will be no way of preventing reasonably good documentation.
"Depth" is one of the most important documentation concepts, especially for large systems. If a system is of any size at all, different users of the documentation will need different levels of detail in the information they extract. The highest level should be just sufficiently detailed to tell the user whether or not he will be able to read the documents. At each level - because we can never be sure which document will fall into the user's hands - the first and most conspicuous thing in the document should be a reference to the documents above and below it in depth, along with an indication of the the depth to which the document goes and the knowledge the reader must have to use it.
We have not accustomed ourselves to thinking of the cost of documentation as a part of the programming cost.
There is no reason to believe that a professional programmer will be qualified as a professional documenter.
This book makes the case that software development is not always just hardware and software. We humans are the main part of the equation and therefore software development carries all the issues and challenges as any other human endeavor.
I really liked the book's description of the greatest challenge as "not creative thinking, but creative communicating: representing our thoughts in a way that other persons - each with a unique style - can understand."
No comments:
Post a Comment