<< Chapter 10: The Documentary Hypothesis
Pilot Plants and Scaling Up
Chemists know that a process that works in the lab cannot be implemented in a factory in only one step. Pilot plants are used to work at an in-between scale.
For software projects, the 1st iteration will almost always suck, its big, slow and awkward to use. Rewrites are almost always necessary; because it is very rare to get it right the first time.
Plan one to throw away, you will anyhow!
The Only Consistency is Change Itself
Accept change:
The programmer delivers satisfaction of a user need rather than any tangible product. And both the actual need and the user’s perception of that need will change as programs are built, tested and used
Changes in objective are inevitable. Changes in development strategy and technique are inevitable.
Plan for Change
You can plan for change using a lot of techniques: careful modularization, extensive subroutining, precise and complete definition of intermodule interfaces, documentation.
Use high-level languages and self-documenting techniques so as to reduce errors induced by changes.
It is essential to quantize changes, use versioning.
Plan the Organization for Change
The reluctance to document designs is not due merely to laziness or time pressure. Instead it comes from the designer’s reluctance to commit himself to the defense of decisions which he knows to be tentative.
Planning for organization change is hard. The project manager may need to keep 2 or 3 top programmers as a technical cavalry to jump into needed areas. Managers and technical people need to be as interchangeable as possible. That means you need to overcome social stigmas (a manager who thinks he’s too “good” to program). Managers need technical refresher courses, and technicals need management courses.
Ultimately, the surgical team format aims to address this problem.
Two Steps Forward and One Step Back
Changes after delivery is known as “program maintenance”. Changes that occur in this time are repairs meant to address design defects.
The cost of maintenance is usually 40% more than the cost of development itself. Also, the process of fixing a bug has a 20-50% chance of introducing a new bug. Bugs usually have system-wide ramifications which are non-obvious. Fixing the local and immediate cause will overlook the systemic roots of the bug. It doesn’t help that the original coder rarely does the maintenance, its usually left to a junior programmer or a trainee.
Introduction of new bugs lead to more testing, more regression tests
Ones Step Forward, One Step Back
All repairs tend to destroy the structure of the software. Eventually, the repairs will be so extensive, and the new bugs so many, that the maintainers spend too much time fixing bugs released from earlier fixes. No new ground is gained. The software doesn’t move forward towards design fixes.
Things are always best at their beginning
3 Trackbacks
[...] Pi/Pi …but that's just one! Skip to content ProjectsCSC309 A3 – kääntää TranslationsCSC309 A1: kääntää TranslationsJump StacksGrksm To UnicodePhotosynth of BahenCSC302 Winter ‘09CSC301 Fall ‘08Project ArgoboxAbout MeContact Me « TMMM – Plan To Throw One Away [...]
[...] Pi/Pi …but that's just one! Skip to content ProjectsCSC309 A3 – kääntää TranslationsCSC309 A1: kääntää TranslationsJump StacksGrksm To UnicodePhotosynth of BahenCSC302 Winter ‘09CSC301 Fall ‘08Project ArgoboxAbout MeContact Me « TMMM – Ten Pounds in a Five-Pound Sack TMMM – Plan To Throw One Away » [...]
[...] If you find that the code is getting messy, cluttered or is just downright wrong; don’t be afraid to throw it away and start over. You won’t be wasting it; I mean, its just data after all. The rewrite will go much faster and the code will be much better as a result. (see Plan to Throw One Away). [...]