Devops for Growth

Five Myths of Traditional Software Development

Traditional software development is based on some principles which are no longer appropriate under this new world of complex environments. It is worth looking at five of these myths.

• The myth of the specification: Traditional software development assumes that the first task is to determine the specification, and all design and development follows after the specification is finalized. More modern approaches stress spiral rapid development methods in which the specification is constantly being refined. The target is really a combination of related components, not a single application.
• The myth of software maintenance: The word "maintenance" gives the impression that the software has somehow degraded, and needs to be refurbished to its original condition. This is misleading. The bits in a program do not degrade. They remain the same, while the environment around the program changes. So it is really a process of upgrading or evolving to meet the needs of the changing environment. By viewing it as a maintenance problem, one risks making the mistake of trying to preserve the old structure when its time has passed.
• The myth of the black box: Abstraction plays a crucial role in the development of reliable software. However, treating a process as a black box with an input/output specification ignores the practical problem of resource usage. When a system built out of these black boxes is too big or too slow, there is no way to improve the performance other than to tear the boxes apart. Some work has been done on the idea of Open Implementation, in which modules have one interface for input/output behavior, and another orthogonal interface for performance tweaking. Adaptive software adds to this by making the orthogonal interface a two way system ÷ there is a feedback loop that provides information on the results of the performance tweaking.

• The myth of design choices: In traditional software development, the designers consider several alternatives to implement each component, and then make choices based on the desired product. The alternatives that were not chosen, along with the rationale for the choice, are then discarded. That means when the environment changes (perhaps a new communications protocol becomes popular, or the user gets a computer that is twice as powerful), one needs to start all over again to see what choices are now the best. Often, the original programmers have moved on, and so their design rationale is lost. The alternative is to capture the design criteria as a formal part of the program, and let the program reconfigure itself, as the environment changes, to optimally satisfy the criteria.
• The myth of the expert programmer: Most programmers have pride in their abilities, and feel they can always come up with a good solution, given a suitable specification of the problem. In reality, programmers are only one resource available to a project, and an expensive resource at that. Furthermore, it is impractical to ship a developer with each program (except for very large and expensive custom applications). This suggests that we find a tradeoff where the programmers and designers do what they can do best ÷ formally describe what the program is trying to do. Then the program itself does the calculating and configuring necessary to achieve these goals in the current environment.