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

Re: [XP] Place for rarified skills?

Expand Messages
  • cg@cdegroot.com
    ... That s a problem that is I think quite specific to C++, which is so baroque that indeed there are corners of the language that are only accessible to
    Message 1 of 20 , Sep 30, 2001
    • 0 Attachment
      David Abrahams <david.abrahams@...> said:
      > b. Any job which really exploits my abilities is likely to result in at
      >least some rarified code.
      >
      >As much as I wish it were otherwise, generic programming and template
      >metaprogramming are hardly "lingua franca" among C++ programmers. Those
      >skills are best applied in environments where flexibility and maximum
      >performance are both required. Also, I enjoy solving difficult problems --
      >often arriving at a solution requires exploiting concepts and techniques
      >outside the knowledge of mainstream programmers.
      >
      That's a problem that is I think quite specific to C++, which is so baroque
      that indeed there are corners of the language that are only accessible to
      specialists. The best solution, of course, is to avoid the language like the
      plague.

      I have programmed the last 3 months mostly in Smalltalk. Before that,
      almost a year mainly Python. Before that, around 5 years in Java. These
      are all very accessible languages where there are hardly any dark
      corners. Especially in Smalltalk, I find that hard problems often have simple,
      accessible solutions that don't need a specialist to maintain them. It's hard
      and extremely challenging to come up with the solutions, but after that it's
      mostly merely writing them down. I take a lot of pride in refactoring the code
      until it's as friendly to the eyes and as accessible as I can make it, and I'm
      quite happy to know that if I am hit by a truck any decent Smalltalk
      programmer can take over (especially after reading the overview document I, er,
      am going to write Real Soon Now ;-)).

      The best expression of intelligence and creativity is to make solutions look
      so obvious that any moron thinks he could have come up with it. As a side
      effect, it means you run less risk of having to maintain your own hacks...


      --
      Cees de Groot http://www.cdegroot.com <cg@...>
      GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B
      "In TriINTERCAL programs the whirlpool (@) denotes the unary tritwise BUT
      operation." -- INTERCAL Programming Language Revised Reference Manual
    • wecaputo@thoughtworks.com
      David Abrahams: I want to say first off, that rarified skills (which I will interpret as skills either the team as a whole does not posses, or are not common
      Message 2 of 20 , Sep 30, 2001
      • 0 Attachment
        David Abrahams:

        I want to say first off, that rarified skills (which I will interpret as
        skills either the team as a whole does not posses, or are not common skills
        or knowledge amongst average programmers) are very much a part of the
        strength of XP. XP teams take advantage of very skilled programmers to
        improve the overall quality of the solutions presented to the customer as
        finished code.

        >So, I'm wondering whether there are experiences of adapting agile
        processes
        >to environments where research, as well as development, is needed.

        If by research you mean looking for optimal ways of solving problems for a
        given design problem within a project, XP teams use something called Spike
        Solutions for this type of research. These are often good candidate tasks
        for people with rarified skills as they can weigh the trade offs of
        different approaches.

        >If your project requires at least some code which solves difficult
        problems with
        >techniques possibly outside the mainstream, do you/can you integrate the
        >author(s) into the XP process, or do they end up isolated?

        As an answer, which is preferable -- to solve such problems in isolation,
        or as part of a collective process? Which will be more likely to
        disseminate such knowledge throughout the team? Which is more likely to
        provide junior or otherwise less skill programmers the opportunity to learn
        more wizardly technique?

        >What about groups where everyone, or most people, need to work at that
        level? Is XP useless
        >there?

        XP is only useless in such a case if the people do not wish to communicate
        the results and techniques they are using with each other.

        I have seen programmers start a project writing 1300 line nested-if,
        copy/paste blocks of C'ish C++ (no templates, no STL, no polymorphism
        etc.), finish the same project (via pairing and collective ownership)
        happily ripping out their old code in order replace it with well factored,
        polymorphic code using templates STL, etc. No formal training, just daily
        working with programmers who knew the more advanced and often useful
        techniques that you describe.

        IMHO A true learning environment is the best way to get these types of
        skills out to programmers who need to learn them. XP is a great way for
        those who do know such techniques to get an opportunity to apply them, and
        help others learn them.

        Best,
        Bill
      • David Abrahams
        ... From: ... Sort of. There are classes of problems which it s not even clear how to /begin/ solving, and which you have to take
        Message 3 of 20 , Sep 30, 2001
        • 0 Attachment
          ----- Original Message -----
          From: <wecaputo@...>
          >
          > If by research you mean looking for optimal ways of solving problems for a
          > given design problem within a project,

          Sort of. There are classes of problems which it's not even clear how to
          /begin/ solving, and which you have to take several stabs at just in order
          to illuminate the nature of the problem so you can find a workable solution.

          > XP teams use something called Spike
          > Solutions for this type of research.

          I don't remember that term from "XP Explained". Is that in there?

          > These are often good candidate tasks
          > for people with rarified skills as they can weigh the trade offs of
          > different approaches.
          >
          > >If your project requires at least some code which solves difficult
          > problems with
          > >techniques possibly outside the mainstream, do you/can you integrate the
          > >author(s) into the XP process, or do they end up isolated?
          >
          > As an answer, which is preferable -- to solve such problems in isolation,
          > or as part of a collective process?

          For me, definitely as a collective process. Often it's hard to find people
          who are willing/able to focus on a difficult problem together for long
          enough to understand it and find solutions. When I can work with people that
          are, I'm in heaven.

          > Which will be more likely to
          > disseminate such knowledge throughout the team? Which is more likely to
          > provide junior or otherwise less skill programmers the opportunity to
          learn
          > more wizardly technique?

          In my experience, you sometimes have to go off and work it out alone or in a
          smaller group... not just because finding an answer is made harder by having
          to bring the less knowledgeable up to speed "all at once", but because they
          become frustrated during these processes because they don't feel they're
          contributing and they could be doing "real work" (meaning work within their
          current grasp).

          > IMHO A true learning environment is the best way to get these types of
          > skills out to programmers who need to learn them. XP is a great way for
          > those who do know such techniques to get an opportunity to apply them, and
          > help others learn them.

          That's very encouraging.
          Thanks, Bill
        • David Abrahams
          ... From: Ron Jeffries ... problems -- ... Hmm, I think you might be misinterpreting me a bit. I believe in doing the simplest thing
          Message 4 of 20 , Sep 30, 2001
          • 0 Attachment
            ----- Original Message -----
            From: "Ron Jeffries" <ronjeffries@...>


            > Around Sunday, September 30, 2001, 5:05:21 PM, David Abrahams wrote:
            >
            > > As much as I wish it were otherwise, generic programming and template
            > > metaprogramming are hardly "lingua franca" among C++ programmers. Those
            > > skills are best applied in environments where flexibility and maximum
            > > performance are both required. Also, I enjoy solving difficult
            problems --
            > > often arriving at a solution requires exploiting concepts and techniques
            > > outside the knowledge of mainstream programmers.
            >
            > I'm going to throw down a bit of a challenge here. I want to suggest
            > -- in a kindly grandfatherly mentoring ancient guru kind of way --
            > that the next level of programming for you to attain is the ability to
            > arrive at solutions to these problems that involve little or no
            > rarified code, and that even if they use specialized techniques, use
            > them in a way that illuminates those techniques for those lesser
            > beings who are following you on the lower rungs of the ladder.


            Hmm, I think you might be misinterpreting me a bit. I believe in doing the
            simplest thing that will possibly work, but other principles sometimes
            oppose that one. For example, I also believe in avoiding code duplication,
            which AFAICT is one important reason for refactoring. I would never apply a
            "rarified technique" where something simpler would do. When designing
            reusable libraries, the rarified technique is often exactly what's needed to
            make life simpler for the library's users.

            ===================================================
            David Abrahams, C++ library designer for hire
            resume: http://users.rcn.com/abrahams/resume.html

            C++ Booster (http://www.boost.org)
            email: david.abrahams@...
            ===================================================
          • Ron Jeffries
            ... For example? Ronald E Jeffries www.XProgramming.com Fear is the mindkiller. --Bene Gesserit Litany Against Fear
            Message 5 of 20 , Sep 30, 2001
            • 0 Attachment
              Around Sunday, September 30, 2001, 9:03:10 PM, David Abrahams wrote:

              > When designing
              > reusable libraries, the rarified technique is often exactly what's needed to
              > make life simpler for the library's users.

              For example?

              Ronald E Jeffries
              www.XProgramming.com
              Fear is the mindkiller. --Bene Gesserit Litany Against Fear
            • David Abrahams
              ... From: Ron Jeffries ... needed to ... Take a look at the boost iterator adaptor library at http://www.boost.org , or better yet,
              Message 6 of 20 , Sep 30, 2001
              • 0 Attachment
                ----- Original Message -----
                From: "Ron Jeffries" <ronjeffries@...>


                > Around Sunday, September 30, 2001, 9:03:10 PM, David Abrahams wrote:
                >
                > > When designing
                > > reusable libraries, the rarified technique is often exactly what's
                needed to
                > > make life simpler for the library's users.
                >
                > For example?

                Take a look at the boost iterator adaptor library at http://www.boost.org ,
                or better yet, read the paper at
                http://www.oonumerics.org/tmpw01/abrahams.pdf. The paper is a tad on the
                pedantic side, but it describes in detail some of the things we had to do to
                make the library easy-to-use while behaving correctly in a wide variety of
                cases.

                -Dave
              • Ron Jeffries
                ... Are we really sure that s the simplest thing that could possibly work? Is that the simplest explanation that could be given to the users of the library?
                Message 7 of 20 , Sep 30, 2001
                • 0 Attachment
                  Around Sunday, September 30, 2001, 9:37:31 PM, David Abrahams wrote:

                  > Take a look at the boost iterator adaptor library at http://www.boost.org ,
                  > or better yet, read the paper at
                  > http://www.oonumerics.org/tmpw01/abrahams.pdf. The paper is a tad on the
                  > pedantic side, but it describes in detail some of the things we had to do to
                  > make the library easy-to-use while behaving correctly in a wide variety of
                  > cases.

                  Are we really sure that's the simplest thing that could possibly
                  work? Is that the simplest explanation that could be given to the
                  users of the library? How much simpler could the library be if it only
                  had to cover 90% of the cases, or 80, or 75?

                  I'm totally blowing smoke here, but are we sure that we have the
                  right partitioning of functionality here? If we were using an
                  aspect-oriented language, might we find some more orthogonal elements
                  to make up this functionality? Might those be fed back into a C++
                  design? What would a LISP programmer do with these problems? Could
                  those ideas feed back?

                  I know from experience that C++ is a hellhole and certainly this
                  doesn't change my view on that. It surely reflects great understanding
                  of the nuances of C++. But are these all things that "had" to be done?
                  What does "had" mean in this context? Is all this really contributing
                  to business value?

                  Again, it's clearly a powerful and creative contribution. But I'm not
                  sure whether it proves your point, or mine.

                  Ronald E Jeffries
                  www.XProgramming.com
                  Life tough is. Then die you do. --Yoda
                • David Abrahams
                  ... From: Ron Jeffries ... http://www.boost.org , ... do to ... of ... Well, that s an interesting question. In this case, the work
                  Message 8 of 20 , Sep 30, 2001
                  • 0 Attachment
                    ----- Original Message -----
                    From: "Ron Jeffries" <ronjeffries@...>


                    > Around Sunday, September 30, 2001, 9:37:31 PM, David Abrahams wrote:
                    >
                    > > Take a look at the boost iterator adaptor library at
                    http://www.boost.org ,
                    > > or better yet, read the paper at
                    > > http://www.oonumerics.org/tmpw01/abrahams.pdf. The paper is a tad on the
                    > > pedantic side, but it describes in detail some of the things we had to
                    do to
                    > > make the library easy-to-use while behaving correctly in a wide variety
                    of
                    > > cases.
                    >
                    > Are we really sure that's the simplest thing that could possibly
                    > work? Is that the simplest explanation that could be given to the
                    > users of the library? How much simpler could the library be if it only
                    > had to cover 90% of the cases, or 80, or 75?

                    Well, that's an interesting question. In this case, the work wasn't done to
                    cover a particular business need. I am absolutely certain that if it were,
                    it would have resulted in several customized iterators and adaptors over
                    time, as opposed to one generalized and reusable component. It's very
                    /un/likely that anyone would ever have refactored these into an appropriate
                    general component, at least not in the business environments I've seen. Good
                    enough? Probably, I guess. Not nearly as rewarding, though. I've had lots of
                    reports from people that they found this work indispensable, and I've
                    re-used it often to handle real business needs.

                    For another example which was developed to cover a business need, see the
                    Boost Python Library. This is without a doubt more general than any single
                    problem of binding Python to C++ requires. But it also handles each of those
                    cases much more cleanly and easily than most other tools. There is a
                    long-term payoff if you need to do the job over and over.

                    > I'm totally blowing smoke here, but are we sure that we have the
                    > right partitioning of functionality here? If we were using an
                    > aspect-oriented language, might we find some more orthogonal elements
                    > to make up this functionality? Might those be fed back into a C++
                    > design? What would a LISP programmer do with these problems? Could
                    > those ideas feed back?

                    Those are all good questions, but I don't think they have much bearing on my
                    assertion: to serve library users with simplicity, one often has to assume
                    the burden of complexity.

                    > I know from experience that C++ is a hellhole and certainly this
                    > doesn't change my view on that.

                    Not a debate I want to enter into. It's good for what it's good for, and
                    other tools are often more appropriate.

                    > It surely reflects great understanding
                    > of the nuances of C++. But are these all things that "had" to be done?
                    > What does "had" mean in this context? Is all this really contributing
                    > to business value?

                    I'm sorry I didn't provide the context for you before, but the iterator
                    adaptor library was developed in my "spare time", and as I indicated above,
                    for no particular business purpose.

                    Hmm, maybe I just don't belong in the business world...

                    > Again, it's clearly a powerful and creative contribution. But I'm not
                    > sure whether it proves your point, or mine.

                    Me, neither. I don't think it proves anything by itself. It's just an
                    example of a complex library which makes otherwise difficult jobs relatively
                    simple. I think you'd have to ask how often the tool gets picked up and used
                    to evaluate its "business value".

                    -Dave

                    ===================================================
                    David Abrahams, C++ library designer for hire
                    resume: http://users.rcn.com/abrahams/resume.html

                    C++ Booster (http://www.boost.org)
                    email: david.abrahams@...
                    ===================================================
                  • david.abrahams@rcn.com
                    ... Wow, I never expected to encounter such blatant language bias here. I thought XP was largely about pragmatism. The problem is not specific to C++ at all,
                    Message 9 of 20 , Oct 1, 2001
                    • 0 Attachment
                      --- In extremeprogramming@y..., cg@c... wrote:
                      > >As much as I wish it were otherwise, generic programming
                      > >and template metaprogramming are hardly "lingua franca"
                      > >among C++ programmers. Those skills are best applied in
                      > >environments where flexibility and maximum performance are
                      > >both required. Also, I enjoy solving difficult problems --
                      > >often arriving at a solution requires exploiting concepts
                      > >and techniques outside the knowledge of mainstream programmers.
                      > >
                      > That's a problem that is I think quite specific to C++, which
                      > is so baroque that indeed there are corners of the language that
                      > are only accessible to specialists. The best solution, of course,
                      > is to avoid the language like the plague.

                      Wow, I never expected to encounter such blatant language bias here. I
                      thought XP was largely about pragmatism. The problem is not specific
                      to C++ at all, though C++ admits a wider variety of techniques and
                      approaches than many languages. Part of what I'm referring to here has
                      nothing to do with languages: it's simply the application of good old
                      Computer Science. If I have to use the NFA-to-DFA construction, or
                      dijkstra's algorithm, I'm already speaking a language that the average
                      programmer doesn't seem to grasp.

                      > I have programmed the last 3 months mostly in Smalltalk.
                      > Before that, almost a year mainly Python. Before that, around
                      > 5 years in Java. These are all very accessible languages where
                      > there are hardly any dark corners.

                      It's very interesting that you'd say so. My experience with Python in
                      particular (and I love Python for its many merits) has been that it's
                      full of dark corners, mostly due to incomplete documentation. I can
                      read the source code to find out what happens, but one shouldn't have
                      to. I can't speak for Java or Smalltalk, and would encourage you not
                      to knock C++ until you've learned to use it with as much authority as
                      the other languages you know.

                      In any case, none of these languages are capable of the combination of
                      flexibility and high performance that can be acheived with advanced
                      techniques in C++. As I've said, I wouldn't use an advanced technique
                      where a simpler one would do - sometimes the problem just demands it.

                      > The best expression of intelligence and creativity is to
                      > make solutions look so obvious that any moron thinks he
                      > could have come up with it. As a side effect, it means
                      > you run less risk of having to maintain your own hacks...

                      No argument there. Why do I get the sense that you don't think I value
                      simplicity and re
                    • david.abrahams@rcn.com
                      ... Actually, I can say this about Java (once again, it s an issue of documentation): The Java libraries documentation goes to great lengths to tell you about
                      Message 10 of 20 , Oct 1, 2001
                      • 0 Attachment
                        --- In extremeprogramming@y..., david.abrahams@r... wrote:

                        > I can't speak for Java or Smalltalk

                        Actually, I can say this about Java (once again, it's an issue of
                        documentation): The Java libraries documentation goes to great lengths
                        to tell you about exactly /which/ exceptions may be thrown from any
                        function, but leaves a much more important corner completely dark. It
                        consistently omits any mention of what the program state is in case of
                        an exception. If you don't know what has happened to the objects
                        you're operating on, writing error recovery code is next to
                        impossible. If you're operating on some critical persistent piece of
                        program state when the error occurs, all you can do is cross your
                        fingers and hope for the best. I would think that would make writing
                        reliable software very difficult.

                        Every language has its dark corners. Those in C++ are different from
                        those in other languages and in some ways more capricious, but at
                        least if you're curious and industrious, light can be found in the
                        Sta
                      • wecaputo@thoughtworks.com
                        ... It is, don t let the incessant off-topic holy war mongers here get to you ; -) It helps if you think of such troll-like comments as people trying to say
                        Message 11 of 20 , Oct 1, 2001
                        • 0 Attachment
                          David Abrahams:
                          >I thought XP was largely about pragmatism.

                          It is, don't let the incessant off-topic holy war mongers here get to you ;
                          -) It helps if you think of such troll-like comments as people trying to
                          say something along the lines of "XP is easier to apply in some languages,
                          than in others." I would agree with that statement.

                          However, it isn't a very interesting or practical discussion topic (IMHO)
                          as the reality of many organizations, and individuals, is that they aren't
                          only using the "easier to do XP" languages. And before anyone goes asking
                          which ones they are, I suggest they look at the archives, there's only
                          about 215 threads on the topic.

                          >Part of what I'm referring to here has
                          >nothing to do with languages: it's simply the application of good old
                          >Computer Science. If I have to use the NFA-to-DFA construction, or
                          >dijkstra's algorithm, I'm already speaking a language that the average
                          >programmer doesn't seem to grasp.

                          This is the more interesting question IMO, and the answer (to summarize the
                          thread) is:

                          1) In XP we strive for simplicity[1] and clarity. So the first response one
                          gets here is a question: "Can the task be completed without putting on the
                          star and moon hat?"
                          2) If the answer is no, then the second response is: "Use spikes to explore
                          the concepts further and find TSTTCPW[2] (we still want this, even if the
                          answer is outside the experience of the average programmer)
                          3) Then the response moves along to: "We are still responsible to the team
                          for communicating the rationale behind the decision. Whether the spike was
                          done alone or as a pair, the implementation of the solution (still
                          scheduled as a task to a story) should be paired. Regular interest,
                          communication, Unit testing, and refactoring rules still apply."
                          4) The next part of the response is: "Having such expertise on an XP
                          project is very important, but not at the expense of team, and learning
                          values." -- IOW knowledge bigots need not apply.
                          5) The final part is: "One person's wizardry is another's "Good old CS".
                          Good design is emergent in XP, not eliminated. Every technique has its
                          place. We are encouraged to oversimplify in the hopes that we can get away
                          with it but, as always let the code, the requirements, and the team tell
                          you what is "simplest".

                          [1] The rules for simplicty (lots of threads here and at the wiki
                          discussing this too):
                          http://www.c2.com/cgi/wiki?XpSimplicityRules

                          [2] The Simplest Thing That Can Possibly Work

                          Best,
                          Bill
                        • peter.sommerlad@itopia.ch
                          ... I ... specific ... and in contrast to Java, you might not need to consider the more advanced stuff in your coding, because C++ is carefully designed to the
                          Message 12 of 20 , Oct 1, 2001
                          • 0 Attachment
                            --- In extremeprogramming@y..., david.abrahams@r... wrote:
                            > --- In extremeprogramming@y..., cg@c... wrote:
                            ...some points about the advanced and bad things about C++

                            > > That's a problem that is I think quite specific to C++, which
                            > > is so baroque that indeed there are corners of the language that
                            > > are only accessible to specialists. The best solution, of course,
                            > > is to avoid the language like the plague.
                            >
                            > Wow, I never expected to encounter such blatant language bias here.
                            I
                            > thought XP was largely about pragmatism. The problem is not
                            specific
                            > to C++ at all, though C++ admits a wider variety of techniques and
                            > approaches than many languages.
                            and in contrast to Java, you might not need to consider the more
                            advanced stuff in your coding, because C++ is carefully designed
                            to the principle that you pay only for what you use.
                            For example, grasping multi-threading is hard and using locks can
                            heavily drain performance of a system, both hurt even the average
                            Java
                            programmer without she being able to ignore them or get rid of.
                            ...
                            > In any case, none of these languages are capable of the combination
                            of
                            > flexibility and high performance that can be acheived with advanced
                            > techniques in C++. As I've said, I wouldn't use an advanced
                            technique
                            > where a simpler one would do - sometimes the problem just demands
                            it.

                            I write C++ code happily using the features available before 1990
                            and only occasionally the "more advanced" features. Nevertheless,
                            C++ provides me much better means of abstraction (OO) as C and
                            can still be easily read if I take care. An additional benefit
                            refraining from the use of exceptions and templates is that it
                            is highly portable, even to platforms where the C++ compilers
                            are nascent (like TPF - regards to my former colleague Paul Trunz).

                            I do not say that templates and exceptions do not have their
                            applicability, but as they used to confuse compilers they still
                            tend to confuse developers, but that is a story true about many
                            languages. So it is not so much a language deficit but a matter of
                            the Idioms and style you are using. And here David is right: "less is
                            more".

                            Yours
                            Peter.
                            --
                            Peter Sommerlad

                            itopia - corporate information technology
                            technoparkstrasse 1
                            ch-8005 z├╝rich
                            tel +41 1 355 56 27
                            fax +41 1 355 56 01
                            mobile +41 79 432 23 32
                            mailto:peter.sommerlad@...
                            http://www.itopia.ch
                          • Ron Jeffries
                            ... I don t think it is bias to call things the way they are. C++ has language features far more arcane than any other language I ve ever used and I ve used a
                            Message 13 of 20 , Oct 1, 2001
                            • 0 Attachment
                              Around Monday, October 01, 2001, 7:22:35 AM, david.abrahams@... wrote:

                              > Wow, I never expected to encounter such blatant language bias here.

                              I don't think it is bias to call things the way they are. C++ has
                              language features far more arcane than any other language I've ever
                              used and I've used a lot. I think Cees called it accurately.

                              > I
                              > thought XP was largely about pragmatism. The problem is not specific
                              > to C++ at all, though C++ admits a wider variety of techniques and
                              > approaches than many languages.

                              C++ prosecution rests. ;->

                              > Part of what I'm referring to here has
                              > nothing to do with languages: it's simply the application of good old
                              > Computer Science. If I have to use the NFA-to-DFA construction, or
                              > dijkstra's algorithm, I'm already speaking a language that the average
                              > programmer doesn't seem to grasp.

                              Well, it's good to be above average, like all the children in Lake
                              Wobegon. But perhaps I digress. Further below, you ask:

                              > Why do I get the sense that you don't think I value
                              > simplicity and readability?

                              I'm going to pretend that's actually a question, hoping that it is,
                              and I'm going to answer it.

                              You started the conversation by remarking that

                              > I've been thinking about where I'd fit into an XP environment, or how agile
                              > processes could fit into the kind of work I do. The quote above really
                              > struck me personally, since
                              > a. It rings true
                              > b. Any job which really exploits my abilities is likely to result in at
                              > least some rarified code.
                              >
                              > As much as I wish it were otherwise, generic programming and template
                              > metaprogramming are hardly "lingua franca" among C++ programmers. Those
                              > skills are best applied in environments where flexibility and maximum
                              > performance are both required. Also, I enjoy solving difficult problems --
                              > often arriving at a solution requires exploiting concepts and techniques
                              > outside the knowledge of mainstream programmers.

                              In subsequent replies, you've said

                              > If I have to use the NFA-to-DFA construction, or
                              > dijkstra's algorithm, I'm already speaking a language that the average
                              > programmer doesn't seem to grasp.

                              and

                              > I would never apply a
                              > "rarified technique" where something simpler would do. When designing
                              > reusable libraries, the rarified technique is often exactly what's needed to
                              > make life simpler for the library's users.

                              and

                              > not just because finding an answer is made harder by having
                              > to bring the less knowledgeable up to speed "all at once", but because they
                              > become frustrated during these processes because they don't feel they're
                              > contributing and they could be doing "real work" (meaning work within their
                              > current grasp).

                              So what I read here comes across as the words of someone who is highly
                              skilled and enjoys exercising his skills to the utmost. I can dig
                              that; certainly if I had any skills I imagine I'd enjoy exercising
                              them.

                              Yet your message comes across as "sometimes we must accept complexity
                              so as to solve the problem".

                              Certainly in some sense that's true: we've all had to solve a problem
                              and had to use or create a complex solution. To me, the question is:

                              Looking upon this hard problem solved with something from deep in
                              our bag of tricks, is our feeling just one of satisfaction?

                              On the one hand, the problem was hard, probably no one else around
                              could have solved it at all.

                              On the other hand, the solution isn't -- by your own statement --
                              simple. When that happens to me, I always feel a little sadness
                              in the satisfaction, because I've had to do something that the
                              average Joe behind me (no offense, Joe) will have trouble with.

                              It's that bit of sadness that I didn't hear in your presentation.
                              That's why I kept pushing on the subject. But I think I'm through now,
                              unless you want to go on. You can solve hard problems, you care about
                              simplicity. One could want no more.

                              "Thank you sir, may I have another?" ;->

                              Ronald E Jeffries
                              www.XProgramming.com
                              Wisdom begins when we discover the difference between
                              "That makes no sense" and "I don't understand". --Mary Doria Russell
                            • Matthew Davis
                              ... needed to ... Would you accept that a rarified technique may turn out to be a good way to remove duplication? Here s my example: In a legacy project we
                              Message 14 of 20 , Oct 1, 2001
                              • 0 Attachment
                                --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
                                > Around Sunday, September 30, 2001, 9:03:10 PM, David Abrahams wrote:
                                >
                                > > When designing
                                > > reusable libraries, the rarified technique is often exactly what's
                                needed to
                                > > make life simpler for the library's users.
                                >
                                > For example?

                                Would you accept that a rarified technique may turn out to be a good
                                way to remove duplication? Here's my example:

                                In a legacy project we have (ugh) a struct.h/cpp set of files. The
                                header defines a bunch of structures - purely data - and
                                prototypes for InitializeXxx() functions for each of them. The .cpp
                                has implementations for each of those structures, which used to each
                                set all the struct members to zero, but had at some point been
                                refactored to memset() the struct to all zeroes.

                                Ignoring for a moment the other 8 gazillion things wrong with this
                                code, I sought to eliminate the massive duplication of 40 functions
                                that all simply call memset, using the parameter type as the size to
                                set to 0's.

                                The most obvious solution to me was a templatized function, which I
                                implemented. It's really pretty simple - but since relatively few C++
                                developers are intimate with writing templates (heck, even I had to
                                look up the syntax to be able to write this function), it's possible
                                that by doing this I've created a barrier to someone else
                                understanding the code.

                                I reconcile this with the thought that the best solution is the best
                                solution, and knowing the language is the responsibility of any future
                                developer working on the code. When I consider using a rarified
                                technique, I think carefully about whether there is a better, less
                                rarified technique. But if less rarified techniques are not as good,
                                then the rarified technique has to win.

                                Besides, this lets me show by example just what is a good use of a
                                rarified technique. :-)

                                (Now to do something about the fact that the InitializeXxx() functions
                                took references rather than pointers, or that the only thing relating
                                the structures to each other is that they are structures, or that the
                                data they contain would probably be better maintained by actual
                                objects...)

                                -Matthew
                              • Keith Nicholas
                                ... I don t think this is the real issue....I think wrapping complexity up in a way that it can be used simply makes it way more useable for the average Joe.
                                Message 15 of 20 , Oct 1, 2001
                                • 0 Attachment
                                  > On the other hand, the solution isn't -- by your own statement --
                                  > simple. When that happens to me, I always feel a little sadness
                                  > in the satisfaction, because I've had to do something that the
                                  > average Joe behind me (no offense, Joe) will have trouble with.
                                  >
                                  > It's that bit of sadness that I didn't hear in your
                                  > presentation. That's why I kept pushing on the subject. But I
                                  > think I'm through now, unless you want to go on. You can
                                  > solve hard problems, you care about simplicity. One could
                                  > want no more.
                                  >

                                  I don't think this is the real issue....I think wrapping complexity up
                                  in a way that it can be used simply makes it way more useable for the
                                  average Joe.

                                  Java, smalltalk etc all do the same thing, they wrap complexity up into
                                  something more simple and accessible to the average Joe. Good example
                                  is garbage collection, as a developer, you don't even think about this
                                  too much, but it is a complex piece of software that someone had to
                                  write.

                                  This is what is being discussed in terms Davids discussion. The
                                  creation of elements of software which simplify development when you
                                  have those elements, but the cost of getting those elements in the first
                                  place might be quite high and involve quite a bit of complexity.

                                  Also maintaining those elements requires someone who can understand the
                                  complexity and advanced techniques that have been used.

                                  In terms of XP, the decision to make "library software elements" that
                                  simplify the overall development is a business decision if they are
                                  going to require a significant amount of effort. However, I think
                                  possibly that these kinds of things really do need to be open source
                                  like boost as it is very hard for one business to get the skills
                                  required to be able to maintain these more advanced software elements
                                  (hard enough to find people with good basic understanding of C++!).

                                  We had a little talk here at our company about Mr Alexandrescus
                                  techniques and decided it would be too hard to get developers who would
                                  be able to work with the code even though the techniques are very
                                  powerful and can be much quicker to write software with.

                                  Keith


                                  > "Thank you sir, may I have another?" ;->
                                  >
                                  > Ronald E Jeffries
                                  > www.XProgramming.com
                                  > Wisdom begins when we discover the difference between
                                  > "That makes no sense" and "I don't understand". --Mary Doria Russell
                                  >
                                  >
                                  > To Post a message, send it to: extremeprogramming@...
                                  >
                                  > To Unsubscribe, send a blank message to:
                                  > extremeprogramming-unsubscribe@...
                                  >
                                  > ad-free courtesy of objectmentor.com
                                  >
                                  > Your use of Yahoo! Groups is subject to
                                  > http://docs.yahoo.com/info/terms/
                                  >
                                  >
                                  >
                                • David Abrahams
                                  ... From: Brian C. Robinson ... Even using STL is not neccessarily generic programming. STL is an example of generic programming,
                                  Message 16 of 20 , Oct 2, 2001
                                  • 0 Attachment
                                    ----- Original Message -----
                                    From: "Brian C. Robinson" <brian.c.robinson@...>

                                    > At 04:05 PM 9/30/01, you wrote:
                                    > >As much as I wish it were otherwise, generic programming and template
                                    > >metaprogramming are hardly "lingua franca" among C++ programmers.
                                    >
                                    > That's why you pair with them. And get them to read some books (Meyers'
                                    > Effective STL and Josuttis' The C++ Standard Library are my
                                    > favorites). Pretty soon everyone in your group will be at least competent
                                    > in the area of generic programming. This is exactly what I did.

                                    Even using STL is not neccessarily generic programming. STL is an example of
                                    generic programming, but most people are using it directly for concrete
                                    jobs, rather than writing new generic components. Not to devalue concrete
                                    jobs (ultimately, they're everything!), but I want to distinguish library
                                    component design/construction from library use.

                                    > >Also, I enjoy solving difficult problems --
                                    > >often arriving at a solution requires exploiting concepts and techniques
                                    > >outside the knowledge of mainstream programmers.
                                    >
                                    > Ah, so "clever" programming.

                                    Emphatically not! I always prefer the straightforward to the clever. I'm
                                    talking for example, about exploiting concepts from "the literature", like
                                    graph theory, parsing technology, linear algebra, pattern matching, etc.,
                                    etc. These concepts and theories are capable of wrapping up a whole lot of
                                    complex thought into simpler packages. Often, seeing a problem in these
                                    terms is what's required in order to make it simple enough to be manageable.

                                    > Are your solutions simple? If so, you should
                                    > easily be able to explain them to your pair.

                                    It depends whether the pair is willing to accept a quick-and-simplified
                                    explanation of the theory or not.

                                    -Dave
                                  • Ron Jeffries
                                    ... I think most people are willing to learn. Honestly, and with the deepest love and respect, it still sounds to me as if the problem is closer to you than it
                                    Message 17 of 20 , Oct 2, 2001
                                    • 0 Attachment
                                      Around Tuesday, October 02, 2001, 12:55:59 PM, David Abrahams wrote:

                                      >> Are your solutions simple? If so, you should
                                      >> easily be able to explain them to your pair.

                                      > It depends whether the pair is willing to accept a quick-and-simplified
                                      > explanation of the theory or not.

                                      I think most people are willing to learn. Honestly, and with the
                                      deepest love and respect, it still sounds to me as if the problem is
                                      closer to you than it is to these other guys.

                                      Ronald E Jeffries
                                      www.XProgramming.com
                                      Accroches-toi a ton reve. --ELO
                                    • David Abrahams
                                      ... From: Ron Jeffries ... That s my experience, too. They may not have the patience to go through the deep explanation, though.
                                      Message 18 of 20 , Oct 2, 2001
                                      • 0 Attachment
                                        ----- Original Message -----
                                        From: "Ron Jeffries" <ronjeffries@...>


                                        > Around Tuesday, October 02, 2001, 12:55:59 PM, David Abrahams wrote:
                                        >
                                        > >> Are your solutions simple? If so, you should
                                        > >> easily be able to explain them to your pair.
                                        >
                                        > > It depends whether the pair is willing to accept a quick-and-simplified
                                        > > explanation of the theory or not.
                                        >
                                        > I think most people are willing to learn.

                                        That's my experience, too. They may not have the patience to go through the
                                        deep explanation, though. Frankly, we may not have the time. Maybe I need to
                                        work on my explanation skills.

                                        > Honestly, and with the
                                        > deepest love and respect, it still sounds to me as if the problem is
                                        > closer to you than it is to these other guys.

                                        I'm not sure there is a problem at all. If there is one, I'd be willing to
                                        accept that it's me; I certainly never imagined that "these other guys" had
                                        a problem. What problem do you perceive?

                                        I'm just interested in finding a place in an XP environment where I can
                                        contribute, and feel like I'm fully used. Since it might be up to me to
                                        create that environment, I'm asking about the experiences of others.

                                        -Dave
                                      • Ron Jeffries
                                        ... Good approach. I think my answer is something like this: You re smart. You know a lot. Therefore you re called on to solve hard problems. Solve them in
                                        Message 19 of 20 , Oct 2, 2001
                                        • 0 Attachment
                                          Around Tuesday, October 02, 2001, 2:09:00 PM, David Abrahams wrote:

                                          > I'm not sure there is a problem at all. If there is one, I'd be willing to
                                          > accept that it's me; I certainly never imagined that "these other guys" had
                                          > a problem. What problem do you perceive?

                                          > I'm just interested in finding a place in an XP environment where I can
                                          > contribute, and feel like I'm fully used. Since it might be up to me to
                                          > create that environment, I'm asking about the experiences of others.

                                          Good approach. I think my answer is something like this:

                                          You're smart. You know a lot. Therefore you're called on to solve
                                          hard problems. Solve them in such a way that you never need to
                                          work on that code again. That is, leave behind you not just
                                          working code, but working, clear code, and at least one other
                                          team member who can do any necessary maintenance.

                                          Details, of course, are left to you. I'm sure you're up to it.

                                          Is that helpful? Or harmful? ;->

                                          Ronald E Jeffries
                                          www.XProgramming.com
                                          Discontinue reading if rash, irritation, redness, or swelling develops.
                                          Especially irritation.
                                        • Keith Nicholas
                                          I don t think this is so much a question about XP but more a more general question of any team based development. It s more a matter of finding a team of
                                          Message 20 of 20 , Oct 2, 2001
                                          • 0 Attachment
                                            I don't think this is so much a question about XP but more a more
                                            general question of any team based development. It's more a matter of
                                            finding a team of developers who you can fit into. Of course one of
                                            your best bets is to create your own XP environment with the types of
                                            developers that you want to work with. The cool thing about an XP type
                                            environment (though not unique to) is that it actively encourages
                                            communication and cooperation with all the team which is a great
                                            opportunity to share knowledge and skills.

                                            The other thing that may be worth thinking about is a catalog of
                                            refactorings specific to generic/template C++ programming. Perhaps
                                            things such as "Replace class with template", "Replace Memory Management
                                            with smart pointer" etc...but perhaps that's better discussed on the
                                            refactoring email list :)

                                            Keith

                                            > -----Original Message-----
                                            > From: David Abrahams [mailto:david.abrahams@...]
                                            > Sent: Wednesday, October 03, 2001 6:09 AM
                                            > To: extremeprogramming@yahoogroups.com
                                            > Subject: Re: [XP] Place for rarified skills?
                                            >
                                            >
                                            >
                                            > ----- Original Message -----
                                            > From: "Ron Jeffries" <ronjeffries@...>
                                            >
                                            >
                                            > > Around Tuesday, October 02, 2001, 12:55:59 PM, David Abrahams wrote:
                                            > >
                                            > > >> Are your solutions simple? If so, you should
                                            > > >> easily be able to explain them to your pair.
                                            > >
                                            > > > It depends whether the pair is willing to accept a
                                            > > > quick-and-simplified explanation of the theory or not.
                                            > >
                                            > > I think most people are willing to learn.
                                            >
                                            > That's my experience, too. They may not have the patience to
                                            > go through the deep explanation, though. Frankly, we may not
                                            > have the time. Maybe I need to work on my explanation skills.
                                            >
                                            > > Honestly, and with the
                                            > > deepest love and respect, it still sounds to me as if the
                                            > problem is
                                            > > closer to you than it is to these other guys.
                                            >
                                            > I'm not sure there is a problem at all. If there is one, I'd
                                            > be willing to accept that it's me; I certainly never imagined
                                            > that "these other guys" had a problem. What problem do you perceive?
                                            >
                                            > I'm just interested in finding a place in an XP environment
                                            > where I can contribute, and feel like I'm fully used. Since
                                            > it might be up to me to create that environment, I'm asking
                                            > about the experiences of others.
                                            >
                                            > -Dave
                                            >
                                            >
                                            >
                                            >
                                            > To Post a message, send it to: extremeprogramming@...
                                            >
                                            > To Unsubscribe, send a blank message to:
                                            > extremeprogramming-unsubscribe@...
                                            >
                                            > ad-free courtesy of objectmentor.com
                                            >
                                            > Your use of Yahoo! Groups is subject to
                                            > http://docs.yahoo.com/info/terms/
                                            >
                                            >
                                            >
                                          Your message has been successfully submitted and would be delivered to recipients shortly.