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

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

Expand Messages
  • Ron Jeffries
    ... Well, as I think I said, I d use what I had learned to write the second one. So I might use the same techniques ... certainly if I was happy with the way
    Message 1 of 17 , Jun 1, 2005
    • 0 Attachment
      On Wednesday, June 1, 2005, at 5:51:25 PM, Steve Bate wrote:

      >> Use what we have learned to build the German one separately; it
      >> wouldn't take long, since it didn't take long the first time.
      >>
      >> Observe the similarities and duplications; extract them, probably
      >> mostly into parameterized tables; perhaps somewhat into strategy
      >> objects or the like.

      > Would you write the German version using the same basic technique
      > as the English version? If so, wouldn't you effectively be rewriting
      > the program twice (once for German and once for the merged version)?

      Well, as I think I said, I'd use what I had learned to write the
      second one. So I might use the same techniques ... certainly if I
      was happy with the way it came out, or if I was looking to converge
      the two solutions, I would.

      I would 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 would be watching for opportunities to reuse what I already had,
      and would use those opportunities as soon as they seemed, well,
      reusable;

      I would then refactor to remove duplication, which is as unlike
      rewriting the code as reordering these three paragraphs would be
      unlike rewriting them.

      Demonstration ...

      I would 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 would then refactor to remove duplication, which is as unlike
      rewriting the code as reordering these three paragraphs would be
      unlike rewriting them.

      I would be watching for opportunities to reuse what I already had,
      and would use those opportunities as soon as they seemed, well,
      reusable;

      Drag, copy, click new location, paste, drag, cut, click new
      location, paste. Not much like rewrite at all. Let's remove more
      duplication ...

      I would ...

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

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

      Ron Jeffries
      www.XProgramming.com
      Curiosity is more powerful than skepticism.
    • Steve Bate
      ... It depends. In this smaller application, the design structure seems reasonable but apparently didn t eliminate the need to rewrite it for the I18N
      Message 2 of 17 , Jun 1, 2005
      • 0 Attachment
        Ron wrote:
        >
        > On Wednesday, June 1, 2005, at 5:13:36 PM, Steve Bate wrote:
        > > It wouldn't be a big problem in this case to rewrite all the
        > > code since it's a relatively small function. This issue
        > > can also apply to larger programs when I18N is added after an
        > > initial implementation (rather than being specified up front).
        > > Rewriting a large application might not be considered an
        > > acceptable solution for some (many?) customers.
        >
        > But rewriting an entire application in order to internationalize it
        > seems extremely unlikely, especially if it has any reasonable design
        > structure at all, n'est pas? Nicht wahr? Eh?

        It depends. In this smaller application, the design structure
        seems reasonable but apparently didn't eliminate the need to
        rewrite it for the I18N requirement. The same could be true
        for some larger applications (and not true for many others).

        Maybe we should be careful in judging the reasonableness of
        design structure based on a need for significant rewrites after
        new requirements are identified. That's more or less why I
        mentioned the metric for design agility. I don't believe it's
        a great metric, but it's one that some people seem to use
        informally to judge other people's designs.

        Steve
      • yahoogroups@jhrothjr.com
        From: Steve Bate To: extremeprogramming@yahoogroups.com
        Message 3 of 17 , Jun 1, 2005
        • 0 Attachment
          From: "Steve Bate" <steve.at.technoetic.com@...>
          To: "extremeprogramming@yahoogroups.com"
          <extremeprogramming.at.yahoogroups.com@...>
          Sent: Wednesday, June 01, 2005 3:13 PM
          Subject: RE: [XP] Design Agility? (was: Duplication vs Intention Revealing
          code)


          >> > Which design would be the most agile given the additional
          >> > requirement and why?
          >>
          >> I'd have to see a representative sample of German numbers
          >> to make any kind of a guess. My German is way too far
          >> behind me to remember much more than ein, zewi, drei,
          >> vier und zwanzig (blackbirds or some such.)
          >
          > http://www.smartphrase.com/German/ge_numbers_voc.shtml
          >
          >> Quite frankly, I wouldn't use that as any kind of a criterion
          >> for agility; I'd expect to rewrite it from scratch and look at
          >> the surrounding system to see how easy it would be to
          >> do that without having to make massive changes elsewhere.
          >
          > It wouldn't be a big problem in this case to rewrite all the
          > code since it's a relatively small function. This issue
          > can also apply to larger programs when I18N is added after an
          > initial implementation (rather than being specified up front).
          > Rewriting a large application might not be considered an
          > acceptable solution for some (many?) customers.

          This is one of those things I consider a "scare story". The
          fact is that an application which is very heavily oriented toward
          text processing in English might need a complete rewrite to
          internationalize it, but most applications that one would want
          to internationalize after the fact aren't quite as text intensive.

          Let's take an example I'm familiar with: PyFIT (the Python
          port of FIT and FitLibrary.) Internationalization is a topic
          we're probably going to be discussing in the next few months.
          From my viewpoint, it's not going to be a difficult problem.

          One might think that Fit does a lot of text processing, and that
          would be true. However, most of the work revolves around
          two issues: converting a "user friendly" name to a Python
          identifier, and localizing error messages on the way back.

          I've already got a leg up on the first because I support both
          batch and FitNesse in one package, which means that I
          already have three different algorithms to convert an external
          name to an identifier, and the mechanism to decide which one
          to use.

          That mechanism is undoubtedly going to have to be extended
          in a couple of ways (one of which I'd be doing anyway, even
          if I wasn't thinking about internationalization), but it isn't going to
          cause a humongous revolution in the code base.

          The other issue is localization of error messages. As it turns
          out, I already have a central table of error messages, indexed
          by code and with parameters to insert. All of that mechanism
          is embedded in one exception. The reason for that table isn't
          looking ahead: the table has 43 messages,
          and I've been a bad boy: there are still quite a few
          places where I just raise Exception with a message. I'm going
          to have to centralize those, but that's a few hours of drudgery
          that is payback for not doing it right once I'd built the mechanism.

          I expect there will be a few more items in the type adapters
          having to do with locale dependent stuff, and a lot of it is
          going to be a learning experiance, but most of it will yield
          fairly readily.

          John Roth






          >
          > Steve
          >
          >
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to:
          > extremeprogramming-unsubscribe@...
          >
          > ad-free courtesy of objectmentor.com
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          >
        • Steve Bate
          ... I ve found that sometimes this is true and sometimes it isn t. There are going to be some subtle and not-so-subtle differences between the languages and
          Message 4 of 17 , Jun 1, 2005
          • 0 Attachment
            Ron wrote:
            >...
            > I would ...
            >
            > 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.
            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.
            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. Or not. It will be interesting if someone provides some
            empirical data on this topic.

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

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

            Steve
          • Ron Jeffries
            ... Well, first of all, it s not an app, it s a function. Second, because it is a few lines, rewriting it seems a reasonable strategy to me. I wouldn t think
            Message 5 of 17 , Jun 1, 2005
            • 0 Attachment
              On Wednesday, June 1, 2005, at 6:55:06 PM, Steve Bate wrote:

              >> On Wednesday, June 1, 2005, at 5:13:36 PM, Steve Bate wrote:
              >> > It wouldn't be a big problem in this case to rewrite all the
              >> > code since it's a relatively small function. This issue
              >> > can also apply to larger programs when I18N is added after an
              >> > initial implementation (rather than being specified up front).
              >> > Rewriting a large application might not be considered an
              >> > acceptable solution for some (many?) customers.
              >>
              >> But rewriting an entire application in order to internationalize it
              >> seems extremely unlikely, especially if it has any reasonable design
              >> structure at all, n'est pas? Nicht wahr? Eh?

              > It depends. In this smaller application, the design structure
              > seems reasonable but apparently didn't eliminate the need to
              > rewrite it for the I18N requirement. The same could be true
              > for some larger applications (and not true for many others).

              Well, first of all, it's not an app, it's a function.

              Second, because it is a few lines, rewriting it seems a reasonable
              strategy to me. I wouldn't think rewriting an entire application
              would seem so reasonable.

              Third, it seems very unlikely to me that every function of the whole
              application could even need internationalization, if it's at all
              well-designed, so that rewriting the entire app wouldn't likely come
              up.

              > Maybe we should be careful in judging the reasonableness of
              > design structure based on a need for significant rewrites after
              > new requirements are identified. That's more or less why I
              > mentioned the metric for design agility. I don't believe it's
              > a great metric, but it's one that some people seem to use
              > informally to judge other people's designs.

              Yes, but there is a very big difference between rewriting, or
              extending, one function, and rewriting an entire application.

              I may be missing something, but the example seems comparable to
              hanging a picture on the wall, and then moving it by pounding
              another nail, and concluding that our house needs to be rebuilt if
              someone brings in a new picture.

              Or something like that ...

              Ron Jeffries
              www.XProgramming.com
              My advice is to do it by the book, get good at the practices, then do as
              you will. Many people want to skip to step three. How do they know?
            • Ron Jeffries
              ... 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.
              Message 6 of 17 , 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
              • Charlie Poole
                Hi Ron, ... I wonder if it isn t confusing the issue to refer to this as I18N. Normally, the term refers to changes that are incidental to the overall purpose
                Message 7 of 17 , Jun 1, 2005
                • 0 Attachment
                  Hi Ron,

                  > > It wouldn't be a big problem in this case to rewrite all the code
                  > > since it's a relatively small function. This issue can also
                  > apply to
                  > > larger programs when I18N is added after an initial implementation
                  > > (rather than being specified up front). Rewriting a large
                  > application
                  > > might not be considered an acceptable solution for some (many?)
                  > > customers.
                  >
                  > But rewriting an entire application in order to
                  > internationalize it seems extremely unlikely, especially if
                  > it has any reasonable design structure at all, n'est pas?
                  > Nicht wahr? Eh?

                  I wonder if it isn't confusing the issue to refer to this as I18N.

                  Normally, the term refers to changes that are incidental to the overall
                  purpose of the application. This particular function has a linguistic
                  purpose
                  at it's heart: performing a limited sort of natural language generation.
                  It
                  isn't at all unreasonable to expect that we might need a different
                  algorithm
                  for different languages - ones we don't know for example.

                  In a large application, I would probably expect to deal with such a
                  function
                  through a Strategy pattern, at least for some languages. I'd implement
                  it as
                  soon as I needed to create a second function. And like you, I'd probably

                  create a second function for the second language. If we had two or three
                  langues implemented and I saw a chance to remove duplication, I'd
                  probably
                  do so, but at that point, I might keep the Strategy pattern, for the
                  time when a
                  language I don't know about came along.

                  That said, it's a fun problem. I've used it as an exercise in C++
                  classes and
                  I think it had the highest variance in terms of length of code needed to
                  solve
                  the problem of any exercise we did.

                  Charlie
                • Ilja Preuss
                  ... test failure: expected but was ;) Regards, Ilja
                  Message 8 of 17 , Jun 3, 2005
                  • 0 Attachment
                    > 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.)

                    test failure: expected <...Vier und Dreiß...> but was <...Fier und Dreis...>

                    ;)

                    Regards, Ilja
                  • Ron Jeffries
                    ... See? I said I couldn t remember ... :) Ron Jeffries www.XProgramming.com Do we learn more through cynicism, or through some other mental posture?
                    Message 9 of 17 , Jun 3, 2005
                    • 0 Attachment
                      On Friday, June 3, 2005, at 10:28:12 AM, Ilja Preuss wrote:

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

                      > test failure: expected <...Vier und Dreiß...> but was <...Fier und Dreis...>

                      See? I said I couldn't remember ... :)

                      Ron Jeffries
                      www.XProgramming.com
                      Do we learn more through cynicism, or through some other mental posture?
                    • Jeff Grigg
                      ... I stumbled across the Mozilla version for German: http://source.x2x2x.org/svn/x2x2x/saxon.net/trunk/Saxon.NET-B-8.4-
                      Message 10 of 17 , Jun 3, 2005
                      • 0 Attachment
                        --- Ron Jeffries <ronjeffries@X...> wrote:
                        > [....] I would expect the big cost in doing the German
                        > version to be the tests. [...]

                        I stumbled across the Mozilla version for German:
                        http://source.x2x2x.org/svn/x2x2x/saxon.net/trunk/Saxon.NET-B-8.4-
                        source/net/sf/saxon/number/Numberer_de.java
                        or
                        http://tinyurl.com/7llcr

                        It looks about like I would expect it to.
                      • Ilja Preuss
                        ... Too much duplication for my taste... Cheers, Ilja
                        Message 11 of 17 , Jun 6, 2005
                        • 0 Attachment
                          extremeprogramming@yahoogroups.com wrote:
                          > --- Ron Jeffries <ronjeffries@X...> wrote:
                          >> [....] I would expect the big cost in doing the German version to be
                          >> the tests. [...]
                          >
                          > I stumbled across the Mozilla version for German:
                          > http://source.x2x2x.org/svn/x2x2x/saxon.net/trunk/Saxon.NET-B-8.4-
                          > source/net/sf/saxon/number/Numberer_de.java
                          > or
                          > http://tinyurl.com/7llcr
                          >
                          > It looks about like I would expect it to.

                          Too much duplication for my taste...

                          Cheers, Ilja
                        • Jeff Grigg
                          ... source/net/sf/saxon/number/Numberer_de.java ... True, but... I found that while German spelling is somewhat more consistent than English, (There are fewer
                          Message 12 of 17 , Jun 6, 2005
                          • 0 Attachment
                            > --- Jeff Grigg wrote:
                            >> I stumbled across the Mozilla version for German:
                            >> http://source.x2x2x.org/svn/x2x2x/saxon.net/trunk/Saxon.NET-B-8.4-
                            source/net/sf/saxon/number/Numberer_de.java
                            >> or
                            >> http://tinyurl.com/7llcr

                            --- "Ilja Preuss" <preuss@d...> wrote:
                            > Too much duplication for my taste...

                            True, but...
                            I found that while German spelling is somewhat more consistent than
                            English, (There are fewer exceptions in the "-teen" and "-ty" ("-
                            zehn/-zig) cases.) their use of compound words and other stylistic
                            variations make it difficult to share the hundred, thousand and
                            million code. When the number of exceptions exceeded the number of
                            instances, I found my data-driven code difficult, and unrolled the
                            loop, much as they have done.
                          Your message has been successfully submitted and would be delivered to recipients shortly.