Re: TDD: Test-Driven Design or Test-Driven Development?
From: Universe (universe_at_tAkEcovadOuT.net)
Date: 02/06/04
- Next message: Universe: "Re: Dijkstra's "Enumeration" = "Metrics" his "Abstraction" = "Quality""
- Previous message: Universe: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- In reply to: Robert C. Martin: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- Next in thread: Paul Campbell: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 5 Feb 2004 18:11:35 -0500
"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:p0o420dvbkickapc5an09gpuuqckbmhrbq@4ax.com...
> On 05 Feb 2004 14:06:09 +0100, Leif Roar Moldskred
> <rmoldskr+usenet@online.no> wrote:
>
> >Robert C. Martin <unclebob@objectmentor.com> writes:
> >
> >> I'd turn that around. Although there can be design activities that do
> >> not involve source code (e.g. certain kinds of diagrams or models) the
> >> activity that truly expresses and determines the design is the
> >> creation of source code.
> >
> >How does this claim differ from the parallel, and clearly spurious,
> >claim that "The activity that truly expresses and determines the
> >design of a ship is welding"?
>
> Welding does not describe the ship. Source code describes the
> program. This ship is the final product, and welding is one small act
> of construction. Source code is not the final product, it is a
> description of that final product. Compiling, linking, deploying, and
> executing are the acts of construction that turn the source code into
> the final product.
>
> Let's say you ask me to build a program for you. I write it in my own
> proprietary language: BOB. There is no compiler for the BOB language.
> There is no computer that can run BOB programs.
>
> Six months later I hand you a BOB source code listing, written by hand
> in ink on paper. Are you happy? Have you relieved the final product?
>
> Source code is not the final product. Source code must be constructed
> into the final product. The final product is a program running on a
> computer.
One reason no genuine model driven design OO engineer considers design to be
anything below a local physical design derived and LED by overall system
architecture designs (logical vs. physical; system vs. subsystem[the latter
Dijkstra distinguishes).
The Code Subsystem, as I've repeated a million times for 10+ years, is but
one major area of DEPLOYMENT.
The Code Subsystem is one of often many other major DEPLOYMENT SUBSYSTEMS.
Like the:
` Network Subsystem
` Data Storage Subsystem
` Security Subsystem
[[[The Security Subsystem, which MUST be CONSCIOUSLY planned EARLY ON into
and with ALL of the other major subsystems (as being listed) and the
subsystem of those major subsystems.]]]
` Hardware Server Platform*s* Subsystem
` Hardware Client Platform*s* Subsystem
` OS Server Platform*s* Subsystem
` OS Client Platform*s* Subsystem
Down With Posturing Amateurishness.
Up With Scientific Professionalism.
Professionalism:
- Expert Skill
- Expert Abstract Reasoning
- Placing Everyday People First
Elliott
-- The thing is that doing holistic investigation and creating holistic plans at all times takes us as far ahead in terms of understanding, as rapidly as possible while enabling us to implement at all times in a way that supports what we know will shortly be incorporated.
- Next message: Universe: "Re: Dijkstra's "Enumeration" = "Metrics" his "Abstraction" = "Quality""
- Previous message: Universe: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- In reply to: Robert C. Martin: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- Next in thread: Paul Campbell: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|