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.
CategoryBooks