TheSourceCodeIsTheDesign is way too long, so I put this here.

Maybe another way of making sense of the design/manufacture metaphor is to regard the code as the detailed design drawing.

For a simple manufactured object, a detailed drawing is all the design documentation that is needed. For a more complex object, a series of layout and general design drawings is required, along with schematics for systems such as pneumatics and hydraulics along with drawings for midprocess states such as castings.

In the software world, the analog of the detailed design drawing is the source code. For more complex systems, we may need other documentation, such as flowcharts, entity relationships, UML, detailed design specifications and so on.

If we accept this metaphor, the cost of manufacture (i.e. compilation) is very small, this and the use of automated tests (which in themselves can be a design document) often make the cost of finding and correcting design defects very low as well. It costs almost nothing to run a test suite to find a bug. If the code is well factored and the test suite well designed, fixing and retesting will be cheap as well.

In contrast, the cost of making, testing, investigating the failure and redesigning a manufactured object will be much higher in relation to the cost of extra design documentation and procedures, that might have prevented the failure.

The use of modern software creation tools has moved us further along this paradigm. When I started coding COBOL on mainframes, it was not uncommon to have to keep compilation logs detailing how many compiles were needed before a program compiled cleanly. Desk checking a program before submitting it for compilation was common. Debuggers were rare.

Nowadays we have quick compilation, debuggers and languages that make the source code more comprehensible. All of these reduce the cost of a debug cycle and change the amount of 'big design' required.

----
CategoryDesignIssues