Re: Re: Communicating design
Hello, Ralf. On Tuesday, June 28, 2011, at 6:55:35 AM, you wrote:
> What I know hear, though, is openess for a different view of the
> programming world where TDD does not work for me (and others). It愀
> not good enough. I feel pain.
I still think that if you feel pain when programming you should do
something else. Pain is nature's way of telling us not to do stuff.
So it makes sense that you might try drawing diagrams.
I do suspect, however, that you do not do things the way I do them,
and I suspect that if you got close to that way, you'd feel less
pain. I could be wrong ... but that's what I suspect.
> To answer that by suggesting people who think differently are either
> not passionate about programming or are just plain less skilled, well,
> is not very polite and in the end does not really further the
> profession, I悲 say.
I can assure you that when programming causes me pain, for example
when I'm trying to make some stupid installation work, I stop doing
what I'm doing, and try something else. I offer that advice quite
sincerely.
Now as for TDD working ...
> I keep hearing "It works for me."
> Then I惴 presenting arguments why there are limitations to what
> "reading the source" can offer.
So far, I guess those limitations do not strike us as limitations we
encounter. I'm not sure why. I suspect they are not specific enough,
or that we have evolved ways of not finding ourselves in the
situations you find painful. Or possibly, we have skills that we
have not mentioned or described, that would alleviate your pain as
well.
> Unfortunately hardly any of my arguments have been taken up by you or
> others to actually discuss them (not just discount them).
First of all, I and others have said, sure, draw diagrams and
discuss them with people. That's not discounting. It seems to me
(and others?) that you have some special kind of diagram that is the
only one that satisfies you. That is interesting but we are not
dissatisfied with what we have.
Second, if we sincerely do not feel the need the kind of diagrams
you do, and we do not feel the pain of programming that you do, does
it not seem reasonable that we may know something about working the
way we do that we have not managed to get across? Does it not seem
reasonable that if you knew it, you, too, might have the same
results we have?
Isn't that kind of how we do science: replicate others' experiments
and then determine how well they work? Isn't it fair for us to
explore whether you've replicated our experiment?
> For example the fundamental argument of text being a poor
> representation of almost anything. Text has its benefits, sure. But it
> 愀 so much harder to understand than more "natural representations" of
> music, math, electrical circuits, bridges and whatnot.
Well actually music and math are specialized forms of text, it seems
to me. Electrical diagrams and bridge pictures, sure. What those
are, it seems to me, is incomplete specifications for how something
is to be built.
And that is the fundamental issue with software diagrams versus
software text. As today's systems work, only the text is truly
definitive about what the software is.
There can be programs that draw diagrams for people to look at.
Those are nice, but they are pictures of the program at a moment in
time, and they are incomplete. The text is (in essence) not
incomplete. Even if we observe that it is still incomplete, for
example because we do not have a library source, the text is still
more complete than any other form.
Even systems where the diagrams generate code have this property.
Generally, the diagram only generates the shell of the program,
inside which we need to put text to represent the rest.
Alternatively, diagrammatic schemes that do allow representation of
all the logic have all turned out to be tedious, not easy to read
after all, and severely limited in what they can do.
The common element today, the one element that can do everything, is
text. We all recommend other diagrams in various ways, and surely
most of us draw them, sketch them, or toss around CRC cards. We've
been saying that in this thread for a month now.
And somehow, despite the fact that what we do satisfies us, it does
not satisfy you. With the greatest respect, I think that puts the
responsibility on you to solve your personal problem, either on your
own or by putting us in a situation where our methods do not satisfy
us, so that we can experience your pain.
> Any design can be codified as text. But except for programmers no
> other craftsman (or engineer or musician) would recommend the textual
> version over a more rich graphical/multi-dimensional version.
In the case of (almost all) programming, the text is a necessary,
final, human form. We are not producing a bridge or an audible song.
We are producing a textual computer program. This changes the value
of the text ... because we cannot get by without writing it.
And still we all recommend drawing pictures as needed.
> This unwillingness to actually discuss TDD (or any other practice) in
> a critical manner is what frustrates me most.
I am not aware of a discussion here of TDD in a critical manner. I
am aware of a bunch of people saying "it works fine for me, in
conjunction with these other practices like whiteboard diagrams,
conversations, tests, ..." ...
I am aware of you saying TDD is not enough for you, and that
programming in text causes you pain. Perhaps, if you really want to
discuss TDD "in a critical manner", we should get more specific.
What I would like to see, though I have no real hope of it, is a
specific example of some smallish problem and solution, worked out
in code plus diagrams your way, and in other people's ways, for
comparison.
Looking at your diagrams, they appear to me to have a fairly
substantial learning curve. I do not see that they offer me enough
benefit to want to undertake to learn them, because the tools,
diagrams, and knowledge I have seem to suffice rather nicely for me.
I think many of us here are in that situation. What we are doing
works for us. What we are doing does not cause us pain. We
understand that if what we were doing were causing us pain we would
be looking for something else. We understand that you feel pain and
therefore want something else. We do not understand why you feel
pain when you do what you //think is// what we do, and we suspect
that you aren't really doing quite the same thing as we do.
Once we determined that you were doing what we do, and saw you point
to some really good code, or some really good sketched diagram and
say "That, that right there. That causes me pain." we might better
understand.
Right now, what we do is satisfying us. We don't understand why you
are not satisfied.
Ron Jeffries
www.XProgramming.com
It is not the strongest of the species that survive, not the most
intelligent, but the one most responsive to change. --Charles Darwin
--
--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_craftsmanship@...m.
To unsubscribe from this group, send email to software_craftsmanship+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
>
> I have a suspicion you'd find some useful similarities in Bon diagrams, see my blog post from
2006
And I will need to
go off my treaden paths.
Check out the AppKatas to get an idea of the size of such an exercise:
RSS Feed