Specs written before code ARE useless, for software is far too complex
for humans to be able to describe accurately without having explored
the problem space in a formal way (for example, by coding it, at which
point the code becomes the spec).
The OSI layer was (and, for the most part, still is) a pre-code spec.
Most successful specs, in particular IETF specs such as the TCP/IP
suite, are *post code* specs; they were written after or concurrent
with code that implements the spec (this is an IETF requirement).
Specs written before coding commit software development projects to a
higher degree of complexity in a single stage of software development
(specification). This additional complexity results in an increased
risk of software defects in that stage and in later stages, and,
independently, increased costs to implement and maintain the software.
Simplicity rules software development. Software projects succeed or
fail exactly because they do or do not prioritize simplicity first.
Humans are cognitively mal-adapted for comprehending non-simple
systems. Exploring the spec formally (by coding it) helps humans
understand complex systems. Specs are not bad, so long as that spec is
code.
These are some of the tenets of Agile software development.
Slashdot Mirror
The OSI layer was (and, for the most part, still is) a pre-code spec. Most successful specs, in particular IETF specs such as the TCP/IP suite, are *post code* specs; they were written after or concurrent with code that implements the spec (this is an IETF requirement).
Specs written before coding commit software development projects to a higher degree of complexity in a single stage of software development (specification). This additional complexity results in an increased risk of software defects in that stage and in later stages, and, independently, increased costs to implement and maintain the software.
Simplicity rules software development. Software projects succeed or fail exactly because they do or do not prioritize simplicity first. Humans are cognitively mal-adapted for comprehending non-simple systems. Exploring the spec formally (by coding it) helps humans understand complex systems. Specs are not bad, so long as that spec is code.
These are some of the tenets of Agile software development.