Loading ...
Sorry, an error occurred while loading the content.

107822Re: [XP] Design Agility? (was: Duplication vs Intention Revealing code)

Expand Messages
  • Ron Jeffries
    Jun 1, 2005
    • 0 Attachment
      On Wednesday, June 1, 2005, at 7:16:17 PM, Steve Bate wrote:

      >> be writing the program once again, but with more knowledge
      >> than last time, so I'd expect it to go even faster and better;

      > I've found that sometimes this is true and sometimes it isn't.

      I've found that this is so close to true that it's well worth
      betting that way. I would expect the big cost in doing the German
      version to be the tests. (Especially since I probably can't remember
      Ein Tausend Fier und Dreisig any more.)

      > There are going to be some subtle and not-so-subtle differences
      > between the languages and the knowledge we gained from the first
      > program might actually be misleading for the additional languages.

      There might be. I don't have that expectation, because what I expect
      to have learned are things like ...

      good ways to handle sometimes-used conjunctions like "," and
      "and";

      good ways to look up words;

      good ways to use functions, and maybe recursion, for common
      string-related things.

      I don't expect to have functions relating to "one" and "eleven" but
      to things like "append 'ty'" and "append 'teen'" ... and to know
      good ways to remove the duplication.

      > It might take more time to undo the clever thinking that worked
      > so well for English and then reorient ourselves to both English
      > and German than it would have to consider them both in the first
      > place.

      Ah. That's why I don't do much "clever thinking". That, and the fact
      that I'm not capable of it.

      > Or not. It will be interesting if someone provides some
      > empirical data on this topic.

      It will. But I don't expect it to generalize very far. I just expect
      it to be another example that producing generalization by
      refactoring specialized code works well.

      >> then refactor to remove duplication, which is as unlike
      >> rewriting the code as reordering these three paragraphs would be
      >> unlike rewriting them.
      >>
      >> be watching for opportunities to reuse what I already had,
      >> and would use those opportunities as soon as they seemed, well,
      >> reusable;
      >>
      >> See? Not like rewrite at all. :)

      > I agree that refactoring isn't a rewrite. The third rewriting
      > is when the first two versions of the program are merged after
      > all refactoring and reuse. However, that might just be a trivial
      > if/then/else (at least for two languages) so maybe it doesn't count
      > as a rewrite. OTOH, for a larger program, the merge might not be
      > quite so simple.

      Why not? A larger program ought to be broken into modules about as
      big as those in the example ... just more of them. The modules
      ought, by the nature and definition of modularity, to be mostly
      independent. So for most incoming changes, only a few modules should
      be affected, and I'd expect them to be affected in ways quite like
      the ways these methods were.

      I wrote a whole book this way, and the same things kept happening
      again and again. I don't think it's an accident, though I do think
      it requires some skill.

      >> > I like this strategy because it will work for additional languages
      >> > (e.g., if I ask for Kanji or Swahili in the next iteration).
      >>
      >> Yes ... and I'd expect that the solution I had would become more
      >> general each time, and that I'd become more experienced (if not
      >> smarter) each time, and that pretty soon I'd be the king of numbers
      >> to text. Maybe. :)

      > I'd expect the same (even the king part). ;-) Of course, my expectation
      > of generality might just be wishful thinking. I've seen business logic
      > become very tangled and messy rather than generalized and elegant as
      > new business rules are added and little exceptional cases are added here
      > and there and then exceptions to the exceptions are added in and so on.
      > And this was with teams who were experienced developers with good
      > refactoring skills.

      I have seen that done as well. I have never seen it done where the
      experienced developers really used their good design and refactoring
      skills.

      I think that an interesting example is the one that Friedrich
      offered a while back, with the folder / file metaphor. The
      developers used an ArrayList whose even elements represented folders
      and whose odd elements represented files.

      This killed them when they needed more than one file per folder.
      However, they were already dead, because the alternating file/folder
      structure isn't even very good for representing a list of files in
      folders ... it has lost information.

      Now it is true that human rules are sometimes quite complex. I
      recall on C3 that there were a handful of employees whose union dues
      were different from anyone else in the company. But that didn't mean
      that the whole application had to become bizarrely complex. In the
      places where it did become too complex, I would say that 90 percent
      or more of the cases were due to us, the programmers, not taking the
      time to make a clean solution, instead just hacking a bag onto the
      side of formerly decent code.

      I am sure that it is theoretically possible to devise a change to
      any given application that will cause massive changes to a large
      number of its modules. But in practice, when a change comes in that
      requires such changes, my experience is not that we were screwed by
      an unexpected change, but that we had already messed up the design,
      even without that change.

      I think that's the way to bet, and all the work I've been doing
      since XP started, and what I've seen from the teams I have visited,
      seems to me to support that notion.

      I could be entirely wrong, of course ...

      Ron Jeffries
      www.XProgramming.com
      New and stirring things are belittled because if they are not belittled,
      the humiliating question arises, "Why then are you not taking part in
      them?" -- H. G. Wells
    • Show all 17 messages in this topic