Prev: Calling same method in inherited classes
Next: sequence diagram for observer pattern
From: Bjorn Reese on 6 Jun 2006 05:50
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?

> The tests are the lubricant that make the changes much more reliable.
> The tests also allow the changes to be made incrementally. Thus TDD is
> a major aid to scalability.

Aren't you comparing apples and oranges? It seems to me that you are
arguing, analogically speaking, that a seat-belt is more important than
a map when you have to drive to a new place. However, both serve
different purposes.

You have argued, to use software architecture terms, that testability is
important because it affects reliability, which is just fine. However,
reliability is not scalability.

You have argued that tests are important to restructuring, which is also
fine. However, restructuring is directionless, whereas architecture is
about direction.

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.

--
mail1dotstofanetdotdk
From: Phlip on 6 Jun 2006 06:03
Bjorn Reese 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?

Looking carefully at the paragraph, I see nothing indicating the source of
tests. I see TDD as the source of the application. How could anyone
responsibly think that paragraph implies tests must not come from anywhere
else?

(I disagree with "full", but it sure beats the odds...)

>> The tests are the lubricant that make the changes much more reliable.
>> The tests also allow the changes to be made incrementally. Thus TDD is a
>> major aid to scalability.
>
> Aren't you comparing apples and oranges? It seems to me that you are
> arguing, analogically speaking, that a seat-belt is more important than
> a map when you have to drive to a new place. However, both serve
> different purposes.

This is the same fallacy. Tests are the steering wheel, engine, and
especially brakes. The map is neither mentioned nor refuted. The paragraph
doesn't discuss how to select which changes to make.

> You have argued, to use software architecture terms, that testability is
> important because it affects reliability, which is just fine. However,
> reliability is not scalability.

He said "major aid to scalability". Not "is scalability".

> You have argued that tests are important to restructuring, which is also
> fine. However, restructuring is directionless, whereas architecture is
> about direction.
>
> 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.

Define "important" as "work on first, and spend a lot of time on".

Define "architecture" as "irreversible design decisions".

TDD is more important than architecture because it makes those decisions
easier to delay and defer. Always delay a commitment to some hard and
irreversible decision. Delay until the last responsible cheap moment, when
you have the most data.

Get those data from all your inputs, including tests.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


From: S Perryman on 6 Jun 2006 07:13
"Bjorn Reese" <breese(a)see.signature> wrote in message
news:44854db8$0$11170$ba624c82(a)nntp02.dk.telia.net...

> 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?

>> The tests are the lubricant that make the changes much more reliable.
>> The tests also allow the changes to be made incrementally. Thus TDD is a
>> major aid to scalability.

> Aren't you comparing apples and oranges? It seems to me that you are
> arguing, analogically speaking, that a seat-belt is more important than
> a map when you have to drive to a new place. However, both serve
> different purposes.
>
> You have argued, to use software architecture terms, that testability is
> important because it affects reliability, which is just fine. However,
> reliability is not scalability.

> You have argued that tests are important to restructuring, which is also
> fine. However, restructuring is directionless, whereas architecture is
> about direction.

> 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.

1. Write a test. Write some code that makes the test execute.

Has that helped you decide the architecture for your radio base station
controller
supporting 500,000 busy hour call attempts ??

2. Write another test. Write some code ...

Has that helped you decide the architecture ...

Carry on there, and tell me what the value of N is (N >> 2 I suspect :-) ) ,
and
what the human effort is (elapsed time, number of developers) for the point
at
which you finally decided your architecture for the radio base station
controller
supporting 500,000 busy hour call attempts.


Regards,
Steven Perryman


From: Bjorn Reese on 6 Jun 2006 10:04
Phlip wrote:

> This is the same fallacy. Tests are the steering wheel, engine, and
> especially brakes. The map is neither mentioned nor refuted. The paragraph
> doesn't discuss how to select which changes to make.

The original claim was:

"But we have learned that the kind of unit tests and acceptance
tests produced by the discipline of Test Driven Development are much
more important [than architecture] to flexibility, maintainability,
and scalability."

As architecture is the map, the map is both mentioned and "refuted"
(please note that I do not interpret Bob's comment as a refutation per
se).

> TDD is more important than architecture because it makes those decisions
> easier to delay and defer. Always delay a commitment to some hard and
> irreversible decision. Delay until the last responsible cheap moment, when
> you have the most data.

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?

--
mail1dotstofanetdotdk
From: phlip on 6 Jun 2006 13:39
Bjorn Reese wrote:

> The original claim was:
>
> "But we have learned that the kind of unit tests and acceptance
> tests produced by the discipline of Test Driven Development are much
> more important [than architecture] to flexibility, maintainability,
> and scalability."
>
> As architecture is the map, the map is both mentioned and "refuted"
> (please note that I do not interpret Bob's comment as a refutation per
> se).

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?

>> TDD is more important than architecture because it makes those decisions
>> easier to delay and defer. Always delay a commitment to some hard and
>> irreversible decision. Delay until the last responsible cheap moment, when
>> you have the most data.
>
> 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?

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