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

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

Expand Messages
  • Ron Jeffries
    ... But rewriting an entire application in order to internationalize it seems extremely unlikely, especially if it has any reasonable design structure at all,
    Message 1 of 17 , Jun 1, 2005
      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?

      Ron Jeffries
      www.XProgramming.com
      If it is more than you need, it is waste. -- Andy Seidl
    • 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 2 of 17 , Jun 1, 2005
        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 3 of 17 , Jun 1, 2005
          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 4 of 17 , Jun 1, 2005
            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 5 of 17 , Jun 1, 2005
              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 6 of 17 , Jun 1, 2005
                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 7 of 17 , Jun 1, 2005
                  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 8 of 17 , Jun 1, 2005
                    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 9 of 17 , Jun 3, 2005
                      > 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 10 of 17 , Jun 3, 2005
                        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 11 of 17 , Jun 3, 2005
                          --- 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 12 of 17 , Jun 6, 2005
                            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 13 of 17 , Jun 6, 2005
                              > --- 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.