Software Handbooks, similar to the handbooks of common techniques used in other engineering disciplines, exist for software in several forms, ranging from very formal
(e.g. Collected Algorithms of the ACM, IEEE Transactions on Software Engineering) collections of formal models, to the practitioner's guides (e.g. book and training course examples, well-documented widely-distributed source code) to the very informal (e.g. USENET technical group archives).
Many attempts have been made to standardize handbooks for the software engineer, which would describe software artifacts at several levels of abstraction from Patterns (analysis level) to Architectures (design level) to libraries (code level). The standards used in the software industry may be at any of these levels of abstraction, i.e. a software handbook may reasonably describe the ISO 7-layer network model and the MVC model from Smalltalk (Patterns), the more detailed APIs given to these models in, say, TCP/IP or Smalltalk (designs), and the code that implements these, in, say, the GNU Repository (code). Little useful work can be done in software until a developer has absorbed a problem, understood its known solutions, and found some set of resources that help him/her construct a new one. Unlike bridges or cars, the exact same piece of software, built a second time, is worth exactly nothing. Software handbooks must concentrate on helping developers to understand what is novel about their problem and solution, and to focus their development effort on what is really new.
See original on c2.com 