Prev: Calling same method in inherited classes
Next: sequence diagram for observer pattern
From: Bjorn Reese on 11 Jun 2006 04:09
phlip wrote:

> We mix metaphors here. If architecture is the map, then is the map the
> path we take to the goal? Or the goal is to draw a map?
>
> Or is architecture the goal, and the map is one of our tools to get to it?

It does not matter. The analogy was used to emphasize the point that TDD
and architecture serve different purposes. Any discussion about the
fine details of the analogy beyond that is vain.

What I am really interested in, is learning why Bob claims that TDD is
more important for scalability than architecture. So far the arguments
have been quite unconvincing, because they have addressed reliability,
not scalability.

>>If I am using an architectural approach that both defers decisions until
>>sufficient information is available, and makes recommendations about how
>>to handle scalability, would you consider it more important than TDD in
>>this regard?
>
>
> Can you think of an "architectural approach" that does all that without
> using tests to analyze situations?

You confuse TDD and tests once more.

Suppose that I could think of such an approach, with or without tests,
but without TDD, would you consider it more important than TDD for
scalability?

--
mail1dotstofanetdotdk
From: Robert Martin on 14 Jun 2006 18:08
On 2006-06-06 11:50:06 +0200, Bjorn Reese <breese(a)see.signature> said:

> Robert Martin wrote:
>
>> When you break the software up like this, you also break the software.
>> You introduce bugs that can be very hard to find. However, if you have
>> written the application using TDD; you have tests that can show you
>> when you have broken functionality. Thus the tests allow you to make
>> the changes with full knowledge of the side effects.
>
> I am slightly confused here. Do you use "TDD" and "tests" as synonyms,
> or are you implying that TDD is the only way to produce tests?

TDD is, among other things, a way to get very high test coverage. It
is also a way to decouple systems which, incidentally, makes them more
scalable.

When you write tests first you create modules that are, by definition,
testable. Testable modules are necessarily decoupled from other
modules in the system. This decoupling enhances scalability. The
tests make sure that you are confident to make changes.
>
> You have argued that tests are important to restructuring, which is also
> fine. However, restructuring is directionless, whereas architecture is
> about direction.

Granted. TDD helps you decouple but does not force good design. Good
design is even more necessary in a TDD environment to help guide the
decoupling.
>
> Architecture will help you to make scalability decisions about:
>
> o Centralized versus distributed architecture
> o Concurrency
> o Load-balancing
> o Data strategies (e.g. stateful versus stateless servers)
> o I/O strategies (e.g. synchronous versus asynchronous interaction)
> o Caching strategies
>
> If you wish to argue that TDD is more important than architecture, then
> you need to start by addressing how TDD helps me to make these
> decisions.

I was not making a comparative argument. TDD is not more important
than architecture, and (in my view) architecture is not more important
that TDD. You need both skills to be a reasonable professional IMHO.


--
Robert C. Martin (Uncle Bob)??| email: unclebob(a)objectmentor.com
Object Mentor Inc.? ? ? ? ? ??| blog:??www.butunclebob.com
The Agile Transition Experts??| web:???www.objectmentor.com
800-338-6716? ? ? ? ? ? ? ? ??|



From: AndyW on 14 Jun 2006 20:36
On Tue, 06 Jun 2006 11:50:06 +0200, Bjorn Reese <breese(a)see.signature>
wrote:

>Robert Martin wrote:
>
>> When you break the software up like this, you also break the software.
>> You introduce bugs that can be very hard to find. However, if you have
>> written the application using TDD; you have tests that can show you when
>> you have broken functionality. Thus the tests allow you to make the
>> changes with full knowledge of the side effects.
>
>I am slightly confused here. Do you use "TDD" and "tests" as synonyms,
>or are you implying that TDD is the only way to produce tests?

I think TDD is a function of an old technique known as incremental
development. The old process was design a little, build a little,
test a little. TDD changes it slightly by moving the test a little
to before the development. One writes a set of tests that satisfies
the design and the developer then only has to write enough code to
pass the tests.

The main benefit is that it reduces cognitive load (if you are aware
of that theory) from the developer. A high congetive load is often
the cause of development defects and design non-conformances.

One still performs the old style integration and system testing.
Remember that one performs verification and validation on all phases
of the software lifecycle, so testing requirements against proposal,
design against requirements, development against design (one would
need to validate the tests in TDD), etc still need to be performed.

I personally use a slightly different approach but the intent is
similar.







From: S Perryman on 15 Jun 2006 03:38
"Robert Martin" <unclebob(a)objectmentor.com> wrote in message
news:2006061500085533169-unclebob(a)objectmentorcom...

> On 2006-06-06 11:50:06 +0200, Bjorn Reese <breese(a)see.signature> said:

>> I am slightly confused here. Do you use "TDD" and "tests" as synonyms,
>> or are you implying that TDD is the only way to produce tests?

> TDD is, among other things, a way to get very high test coverage. It is
> also a way to decouple systems which, incidentally, makes them more
> scalable.

> When you write tests first you create modules that are, by definition,
> testable. Testable modules are necessarily decoupled from other modules
> in the system. This decoupling enhances scalability. The tests make sure
> that you are confident to make changes.

How are you defining "testable" ... ??


>> Architecture will help you to make scalability decisions about:

>> o Centralized versus distributed architecture
>> o Concurrency
>> o Load-balancing
>> o Data strategies (e.g. stateful versus stateless servers)
>> o I/O strategies (e.g. synchronous versus asynchronous interaction)
>> o Caching strategies
>
>> If you wish to argue that TDD is more important than architecture, then
>> you need to start by addressing how TDD helps me to make these
>> decisions.

> I was not making a comparative argument. TDD is not more important than
> architecture, and (in my view) architecture is not more important that
> TDD. You need both skills to be a reasonable professional IMHO.

I work on large systems, with complex architectures.
Which are flexible, scalable, highly testable.

But I don't use the TDD approach.
Am I a "reasonable" (whatever that is) professional ... ??


Regards,
Steven Perryman


From: Bjorn Reese on 15 Jun 2006 09:38
AndyW wrote:

> I personally use a slightly different approach but the intent is
> similar.

Can you elaborate on this approach?

--
mail1dotstofanetdotdk
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Calling same method in inherited classes
Next: sequence diagram for observer pattern