Re: TDD: Test-Driven Design or Test-Driven Development?

From: Robert C. Martin (unclebob_at_objectmentor.com)
Date: 02/09/04 

Date: Sun, 08 Feb 2004 19:32:36 -0600

On 8 Feb 2004 11:28:07 -0800, cycoe@hotmail.com (Cy Coe) wrote:

>Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<0inb20ls0sgnbt44q83kk337urhiggtmqu@4ax.com>...
>> On 7 Feb 2004 08:58:15 -0800, cycoe@hotmail.com (Cy Coe) wrote:
>
>> >But you've encouraged developers to feel like failures for resorting
>> >to UML for expressing their design ideas - all for the sake of
>> >doctrinal purity.
>>
>> Yes, I state that very strongly. I want people to think *first* about
>> how to improve the code to express their intent. It is only when they
>> fail to express their intent in code that I want them to resort to
>> ancillary documents or comments in the code.
>
>What you've failed to express (at least in this post) is the "why"
>behind this. What makes having the code express everything so damn
>important that you would have people going through such pains to try
>to make this happen?

Because, in the end, the code is the product. If we are going to
invest effort in something, it had better be the artifact that is most
critical to the success of the project -- the code.

>Yes, having redundant expressions of something
>causes synchronization issues and entails a certain overhead. But I'm
>not convinced that this attempt to squeeze everything into the source
>code results in less overall effort, or better communication.

I'm not interested in squeezing square pegs into round holes. I just
want to make sure that every round hole is filled with the appropriate
peg. I want to take every possible opportunity to get the code to
express itself well. When I can't, I can't, and I'll use some other
medium.

>Aren't
>there diminishing returns as you start to approach the point of zero
>ancillary documentation?

I'm sure there are. I don't think most developers ever get close to
them.

>This is why I start to wonder if the
>motivation behind this philosophy of source code primacy is as
>political as it is pragmatic.

Shadows lurk in every corner, eh?

>> I don't want people patting each other on the back about the great UML
>> diagrams they drew. I want them regretting that they had to resort to
>> UML instead of expressing themselves in code.
>
>So use of UML should be safe and legal, but rare (to borrow language
>from another debate).

I'm not quite comfortable with this. I'd rather just let the team
decide how much UML they need. I don't want a process dictating this.
>
>> I view UML, and all other forms of ancillary documentation, as a
>> compromise. We have to use them because our languages are not
>> expressive and complete enough; and we are not talented enough.
>
>To me, this sounds like a violinist lamenting the fact that you can't
>play a symphony with only violins.

Perhaps. However, in real life, this particular symphony *is* played
only by the code. The code is the final product.

>Visual modeling is too powerful a
>tool to be treated as a last resort or as something shameful to use.

I quite agree. I use UML at whiteboards quite frequently. I don't
worry at all about that. Let developers brainstorm all they want with
UML on the wall, or on paper. No problem. I don't want the process
telling me that certain UML documents need to be created. I don't
want the presence of certain UML diagrams to be "the documentation" of
the system.

>And while you claim to be liberating developers from the drudgery and
>waste of doing modeling and documentation "because the process tells
>them to", you've still fencing them in, just in a different way.

Quite the contrary. If you need a document, produce it. If you need
a UML diagram, draw it. If you want to brainstorm in UML with a bunch
of other guys at the board -- do it. But don't pat yourself on the
back afterwards and think you've documented the system. Take pains to
get the code to express the intent that you derived from the diagrams.
>
>"Yeah, you build a great piece of software, but you had to resort to
>UML to design it. Deduct half a point."

Again, I write books and articles about using UML to design systems.
I don't deduct for it. UML is not the devil.

>The only difference is that
>instead of being overtly dictatorial, you've trying to set up a
>culture where peer pressure does the dirty work for you. "Real
>programmers don't draw diagrams."

I make no such claim, and think that the claim is idiotic.

>I do believe that you guys are running a somewhat coordinated campaign
>on forums such as this, but the fact that the stories sometimes differ
>between certain parties shows that it is not as coordinated as some
>might think.

Nah, it's just a bunch of guys. There's no coordination. Ron and I
do not strategize about how to answer this or that post. We do not
meet regularly to discuss our internet strategy. It's just a bunch of
guys posting when we feel like it.

Relevant Pages

  • Re: PHP and Diagram Tool
    ... UML isn't that simple at all. ... It may well be that the OP wants more detailed documentation and a few relationships in which case diagrams are _not_ the way to go at all. ... All-in-all I would rather spend the time others spend on pretty pictures, doing written documentation and exercise code. ...
    (comp.lang.php)
  • Re: Why is Delphi more RAD than C++ ?
    ... question your preference not to use UML - like you say, ... class diagram I had just done and realized there was a class in my ... plain useless. ... documentation for them. ...
    (borland.public.delphi.non-technical)
  • Re: Q: Solutions for requirements tracing (to design, code, and test items)
    ... This is the way translation tools like PathMATE handle documentation. ... If you are doing UML models for the design, most drawing tools allow the application of such tags to model elements fairly painlessly. ... Now that OMG is standardizing tools through MDA, most UML drawing tools offer an XMI or equivalent access to the tool repository to extract the tags and their association with model elements. ...
    (comp.object)
  • Re: History of UML diagrams UML 1.0 to UML 2.0
    ... >> I am looking for documentation on the diagrams of UML. ... > The third edition is updated for 2.0, and describes what has changed over the years. ...
    (comp.object)
  • Re: Documenting Large Prolog Systems
    ... I have documented large Prolog systems, and it is not too hard. ... any of the off-the-shelf documentation tools like UML will be tortured if you ... document the main predicates -- not the helpers which are only there to ... Something like UML, ...
    (comp.lang.prolog)