Implementation Driven Development

"I just write code that works, theory comes later."

[WORK IN PROGRESS]

1. Implementation Driven Development, IDD for short, is a software development methodology. ^[1]

1.1. The discipline is formal (as opposed to agile, i.e. informal).

1.2. The process is evolutionary (as opposed to e.g. iterative: the immediate difference being that evolutionary is ideally continuous, though it has milestones, too).

1.3. The aim is *verified highest-quality software at the lowest cost*!

2. Development starts with specification and proceeds top-down (logically, in practice with feedback loops) to implementation and eventually deployment.

2.1 All artefacts ("deliverables") must be runnable, starting with specifications.

2.2. All artefacts must satisfy the formal requirements of consistency, correctness and closedness.

...to be continued...

[1] A precursor is in my TicTacToe project documentation (2007), where for the first time I have mentioned the idea and the name publicly.

[CREATED 2023-05-08 18:41 UTC+2]

Against Test-First

Against Test-First in synthesis:

CONS:

• obliterates the separation coder/tester;

• negatively affects product quality:

• obliterates technical analysis/specification
  (which is the fundamental aberration, in theory and in practice)
  => conflating problem with solution domains;

• negatively affects product/process development:

• obliterates external/internal distinctions (up to the worst RAD)
  (yet what we develop is *what allows building* what we sell, not directly it: whence, together with reasons of intrinsic and utmost complexity, software production driven by the commercial-PM-QA functions, once upon a time rather auxiliary, is just doomed)
  => no development proper: no consolidation of assets, nor of (sane) processes, even less of competences and the chance itself of acquiring those competences;

• enforces the gradual local change (up to TDD)
  (yet the normality hypothesis here is false)
  => no restructuring, no global perspective;

• glorification of the trial and error
  => no improvement, no global sanity.

PROS:

• none known so far!

See also:

• the notion of complex system up to that of phase transition in particular;

• the need for "radical (global/strategic/discontinuous) change" vs "gradual (local/tactical/smooth) change": the history and need for BPR over TQM specifically.

[CREATED 2023-04-11 21:49 UTC+2]