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] [2]}

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 soundness, correctness and closure.

(TECH: Strive for *no bugs*, rather keep closure by wrapping *every hole* into an "exception" - that is a "todo" in documentation.)

...to be continued...

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

[2] A concrete example is the progression of my experimental constructive logic solver (2024), see the revision history in particular.

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

Collective disaster

"Your code might not be as valuable as you think."
Philomatics, The Value of Source Code, YouTube
Subtitle: Your code is worthless

The video is as cute as it is totally misguided. Not all code, just the poorly thought out and written code that is ubiquitous nowadays, in all guidance as in all practice, is actually a cost, not just worthless: a generally unperceived cost since that is 99% of the industry by now, indeed the very rationale that founds and sustains it is that that is the best we can do.

The fundamental misconception that the problem domain and the solution domain map one-to-one is but one ingredient of that yet-another global corporate-driven fraud and collective disaster.

Against Test-First

Against Test-First in synthesis:

CONS:

• negatively affects product quality:

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

• obliterates the separation coder/tester
  (akin to validating data models against the training sets)
  => conflating QA with the methods of production;

• 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 for program code is false)
  => no restructuring, no global perspective;

• glorifies and institutionalises 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]