Part 1: An Overview of Design-by-Induction


Terminology is always a humpty-dumpty game - let me start with what I mean when I say "development" and "design".

I use the word "development" to cover all the various activities of producing software. So I would minimally include under that heading analysis, design, coding, testing, debugging, packaging and distribution. And anything else you want to throw  into the mix such as design/code reviews, planning, estimation, and anything I have forgotten.

Whereas I use the word "design" to cover a particular activity. Analysis tells us what behaviour we want. Coding is building a program that provides behaviour. Design is the set of activities that bridges the gap between the two. Sometimes we need a lot of design. Sometimes we need no design, because we have seen a previous example that we can copy or trivially adapt.

Not everyone uses the word design to mean the same thing. Often this is because people try to formalise the process (which I have no trouble with) and then insist that that is the only legitimate approach (which is unlikely to be correct). My description is deliberately informal because I don't think anything more formal can be justified.

Incremental Development, Incremental Design

And, now we can move onto the word "incremental". This really means interleaved as opposed to being in a single block. "Incremental development" thus means developing with the deliberate intention of interleaving all the different activities. It implies that we are exploiting the interleaving to give us some kind of advantage.

"Incremental design" is not a standard phrase and in this case a more sympathetic phrase would be "design-by-example" or, the phrase I will use, "design by induction". The central idea is that the design process as follows:

    create a null implementation
       pick a feature from analysis
       define an example that illustrate the feature
       challenge the implementation with the example (a.k.a. "test")
       modify the implementation to meet the challenge 
          WITHOUT failing any previous challenge

There are several advantages to this process. The design process naturally becomes incremental (makes for early feedback), the people are working with concrete examples (good for communication, good for focus), and the process has the allure of steady forward progress.

But are three disadvantages to this design strategy. The first is that the design is embodied in the evolving implementation, which makes getting an overview difficult and sometimes intractable (so new recruits to a project take a long time to contribute). The second is the potential risk that the design is suboptimal in some important dimension: speed, space, robustness, cost, time to develop, future-proofing, risk of failure, etc. The third is the potential risk that the design process will completely dead-end.

I think this deserves some proper illustration. So in the next sections I take a well-known example by a top-class writer and critique it as an example of incremental design. Then I rework the same problem using design-by-abstraction as an alternative design strategy and compare the two.

Up to Contents - Forward to Part 2