In 1975 Ted Herman, (of Tinimen Corporation) wrote a 1-page paper relating to organic program design [1]. At the time, there were many advocates of the notion that the activities of making software should be separated, i.e. design and coding. Herman’s “polemic foray” into programming methodology questioned this separation. Aptly put by Henry F. Ledgard (in Programming Proverbs, 1975), “Think first, program later”. Forty years later this “separation” is still one of the most touted approaches to making software.
However anyone who has actually constructed software will realize that this approach is somewhat of a fallacy. It reduces the art of coding to a “thoughtless process” (in the words of Herman). There is no guarantee that the design won’t contain flaws. This is not dissimilar to an architect designing a building, and having little regard for the builders who must actually construct the edifice. Building software is an organic process, whereby the design is not fixed before coding. In reality, real software is often created through coding interspersed with fragments of design. Not much different to how things are built in woodworking – I will have a rough design of what I want to build, but the design may change along the way, maybe due to interaction, or maybe due to roadblocks encountered along the way.
Designing a program for me is more of an experimental process than one steeped in a rigid notion of design-code-test-repeat. In many ways organic design is more agile, not inflexible, and not design heavy. This is extremely important when re-engineering a piece of code, as an overall approach to the refactoring is important, however how the code reacts is never known until the refactoring begins.
[1] Herman, T., “Organic program design: A programming method which mixes design and coding is espoused”, Proc. ACM Ann. Conf., p.356 (1975).
The Craft of Coding 