Kent Beck writes:
> The only way to believe this is to experience it. Get the free version of
> VisualWorks and the Refactoring Browser. Build your favorite simple little
> program. Then start slamming the design around in the code.
I have done using the above tools in the past. I agree it makes things
far easier. I don't agree that it always makes every change easy or
trivial all the time. IMHO there are architecturally deep/broad kinds
of changes that sometimes need to be be made that are painful no
matter how spiffy your toolset. The above tools make such changes
*easier*, but it by no means makes them *easy*.
The hardest is part is figuring out what to change the code into (not
what to change, but what the resulting code is to be added and how its
going to get the information it needs to do what it now needs to do). I
find this *always* takes a non-trivial amount of time and thinking.
Even when you do refactor mercilessly and say code once and only once,
and write unit tests first and pair-program do the simplest possible
things. I have done all of these before (even all on the same project
iteration in the past). Sometimes there is a *big* difference between
"simple" and "simple as *possible*" ;-)
I find that (for my customers at least) they have a nasty knack of
being able to come up with new and changed requirements so are so
radically different from anything either they or I communicated
about before, that even the most amazing combination of these tools
and practices does not make such a change *easy* when it has such
thorny architectural implications that are way beyond the quick-n-easy
kind of hierarchical algebraic/matrix-like manipulations that such
tools let you do with the mixing and matching across the dimensions of
classes and methods/features both up & down the containment and
Now, my customers are typically fellow programmers, so maybe they do
this just to keep me gainfully employed :-) But this is why I still
just don't buy the arguments thus far that code is "easy" to change.
Because I've used many of the tools and practices you describe together
and there are still a non-negligible number of times where the tools
certainly make my like *much* easier, but it still aint easy (not by a
> Once I got good at this, I was able to apply the same style of development
> to Java. It's easiest in VisualAge Java, but I've done it in Cafe also.
> Someone else will have to speak to the possibility of doing it in C++.
I think the Genitor C++ editing environment makes this sort of
thing equally easy in C++ as it is in VisualWorks. The ISE Eiffel
environment does this too (but it takes a little bit of getting used
to the metaphor of "dropping stones" into icons ;-)
-- Brad Appleton <email@example.com> | http://www.enteract.com/~bradapp/ "And miles to go before I sleep." | 3700+ WWW links on CS & Sw-Eng +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Do NOT sent signoff request to firstname.lastname@example.org, please!!! To unsubscribe from this list, please send email To: Subject: <BLANK> Body: unsubscribe otug your_full_subscription_address
This archive was generated by hypermail 2b29 : Thu Jul 13 2000 - 22:37:57 EDT