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

Re: [agileDatabases] Re: [AM] The DAMA crowd misses the point yet again

Expand Messages
  • Clifford Heath
    ... You read it very differently that I did. When he says Scott says.... the implication is.... , and I read it as Scott says.... and so people do.... . He s
    Message 1 of 11 , May 5, 2007
    • 0 Attachment
      On 05/05/2007, at 11:08 PM, Scott Ambler wrote:
      > You'll have to excuse me if I get upset when people
      > libel me.
      >> I think you need to consider Dan's "implications" as
      >> descriptions
      >> of phenomena. IOW, they describe things he's seen.
      >
      > Good for him. Why is that nonsense associated with my
      > writings then? Particularly when a lot of it is the
      > exact opposite of what I've written?

      You read it very differently that I did. When he says
      "Scott says.... the implication is....", and I read it as
      "Scott says.... and so people do....". He's definitely
      getting stuck in, but not on the basis of what you
      say... rather on the basis of what people do. I can't
      reason why he blames you, but my only surmisal is
      that he picked you as a representative of Agile in the
      whole, and he's seen lazy incompetents (such as
      populate a lot of the software development world)
      justifying their predilections by calling themselves
      Agile. IOW, he blames you for excuses made by other
      people about their inadequacy, because he thinks
      that Agile has legitimised those excuses. And to some
      extent, I think he's right that it has - I've seen that
      behaviour too. That doesn't mean that either you
      or Agile *deserves* blame...

      Nevertheless, the behaviour is real, and the Agile
      movement must deal - as it tries to - with human
      weakness, not just instruct the strong and willing.
      If you start with a sufficiently dim view of human
      nature, you'll soon see why Dan blames Agile.
    • Scott Ambler
      Just thought I d start a new thread seeing as the topics were different. Comments below. - Scott ... Heath wrote: ... modeling
      Message 2 of 11 , May 5, 2007
      • 0 Attachment
        Just thought I'd start a new thread seeing as the
        topics were different.

        Comments below.

        - Scott

        --- In information_modeling@yahoogroups.com, Clifford
        Heath <clifford.heath@...> wrote:
        <snip>
        >
        > That's what Object Role Modeling, or fact-based
        modeling does.

        ORM is interesting and is one of the techniques that I
        promote at www.agilemodeling.com/artifacts/

        > Information models created in this way are at a
        higher level
        > than either UML (and other object modeling
        approaches) or
        > traditional ER (entity-relationship) data modeling.

        It would depend on how you apply those techniques.
        ORM is finer grained. David Hay wrote a pretty good
        article on this a few years ago. His site is
        http://www.essentialstrategies.com/

        >
        > With a model in elementary form, it's child's play
        to check its
        > correctness,

        Observation: Working software can be validated pretty
        easily by tests and by actual usage of its
        stakeholders.

        <snip>
        > which gives the designer a greater power to
        > express business rules than either.

        I highly suspect that we can do the same thing with
        source code, and having executable software as well.


        >
        > After the model has been fully validated, tools can
        automatically
        > construct correct, efficient and fully normalized
        aggregations
        > (both class hierarchies and entity-relationship
        models) that are
        > provably congruent.

        What tools would those be?

        What domain are you working in that you need to prove
        congruency?

        >
        > I've been using this technique for more than twenty
        years and
        > I can't believe it hasn't taken off like wildfire,
        it's just so
        > effective.

        Probably because the notation is a bit difficult to
        master. There are significant barriers to entry to
        ORM because of this difficulty. I suspect it will
        always be a niche notation as a result.


        > I put that down to a lack of the right kind of tool
        support, and

        Tool support is critical. However, didn't Microsoft
        go down this route a couple of years ago and fall on
        their sword?

        What are you going to do about the difficulty of
        learning the notation? Without dealing with that
        challenge I suspect that the tooling will struggle.

        > that's the reason why I'm currently building some
        open source
        > tools that fill in some of the gaps. My approach

        Excellent! We definitely need better tooling for
        data-oriented development.

        Are you building the tool using the tool?

        Have you modeling the tool using ORM?

        Are you taking a TDD-based approach?

        > doesn't entail
        > code generation like previous tools, but instead
        creates "executable
        > models". That means that each model is completely
        dynamic, which
        > makes it very suitable for an Agile approach. I've
        been sending
        > status announcements to the Yahoo group
        "information_modeling".

        How do you intend to convince agilists to model to
        this extent? There are some pretty good modeling
        tools already, yet I don't see the hordes of agile
        developers flocking to them.

        > My software isn't ready for use yet, and I'm not
        writing to promote
        > them, but watch this space.

        Cool. Will do. Once you have something solid to
        share with folks, please feel free to announce it on
        the AM list. I can't speak for Pramod who admins the
        AD list, but gut feel tells me that he'd be ok with
        you announcing there too.

        >
        > In the meantime, I'd like to see some effective
        discussion of Object
        > Role Modeling. I truly believe it has the right
        answers here. I'll write
        > more about why if I get an interested response from
        these lists.

        I'd highly suggest getting David Hay and Terry Halpin
        involved with the discussion.

        - Scott

        Scott W. Ambler
        Practice Leader Agile Development, IBM Methods Group
        http://www-306.ibm.com/software/rational/bios/ambler.html

        __________________________________________________
        Do You Yahoo!?
        Tired of spam? Yahoo! Mail has the best spam protection around
        http://mail.yahoo.com
      • Jon Kern
        agile schmagile... The first slug of slides (which i have not gotten past yet) pointing out realities of some development efforts being lousy has nothing to do
        Message 3 of 11 , May 5, 2007
        • 0 Attachment
          agile schmagile...

          The first slug of slides (which i have not gotten past yet) pointing out
          realities of some development efforts being lousy has nothing to do with
          agile and everything to do with people doing a lousy job at software
          development. News flash: anyone can screw up doing a project or
          misinterpret principles of development. Is that somehow the fault of the
          Agile Manifesto? I propose to consider it be the responsibility of the
          people involved...

          If I get the stamina to respond I will, but here is just one stupid example:
          "Who’s definition of ‘working’ shall we use, since we don’t have any
          requirements to
          meet?"

          It would be like me saying:
          "Why bother getting the DBA involved because all they will do is screw
          up the design by ignoring the domain model and over building the data
          model to meet all sorts of needs not yet defined. And worse, they screw
          up all the class names with stupid prefixes."

          DUH!

          I am going to work to respond and not simply react... my guess is i will
          eventually find good words of wisdom in Dan's presentation once i get
          past the incorrect binding of stupid non-agile development habits as
          being how agile projects are all run.

          I wonder how many properly run agile projects Dan has been involved with
          personally? My bet is zero. Dan?

          I personally preach against all that you incorrectly attribute to
          "agile" --- DUH

          Why just the other day, I even created a page on the project wiki for
          standards, and it started with database standards, believe it or not!
          And these were proposed and sample in form... i asked for the database
          guy to chime in with whatever standards they were using.

          Hang around sometime. We may not be quite as stupid as you think.

          jon
          blog: http://technicaldebt.com



          Clifford Heath said the following on 5/4/07 10:44 PM:
          >
          > Scott Ambler wrote in agilemodeling@yahoogroups.com
          > <mailto:agilemodeling%40yahoogroups.com>:
          > > Yikes.
          >
          > Scott,
          >
          > To some extent I share your strong feelings at the style of
          > Dan's presentation, but he has some valid points and I don't
          > think the manner of your response is doing you any favours.
          > A presentation like this needs to be punchy, and I don't see
          > the omission of attribution to be a serious problem; you're a
          > public figure, and anyone can Google up any of your quoted
          > statements and find the sources. To make insinuations about
          > copyright infringement is just plain childish. But enough about
          > that...
          >
          > You talk about "data management politicians" in your 2nd
          > response. In fact, such people generally act as bureaucrats.
          > Bureaucrats act as rule enforcers, whether the rules make
          > sense or not, and generally refrain from entering political
          > debates. Politicians OTOH act by persuading the public of
          > what rules and changes in the rules make sense. In this
          > sense you act as a politician - a laudable role. I think you
          > can see why I've characterised the groups this way. Perhaps
          > it's also part of the reason why they don't join your mailing
          > lists - it's too political for them and that personality type has
          > no taste for that - they prefer analysis to argumentation, and
          > rhetoric to dialectic. Nevertheless, we'll make more progress
          > the better the two groups collaborate, however hard that may
          > be.
          >
          > For that, I have some suggestions below - but first, I'll deal
          > with a couple of further issues arising from your responses.
          >
          > > BTW, my August
          > > column in DDJ will overview the results of a recent
          > > survey that we ran. The survey asked about the
          > > effectiveness of various development techniques,
          > > including both agile and traditional, and apparently
          > > in practice the agile techniques are measurably more
          > > effective. Details to come.
          >
          > Perhaps, but this is definitely not a scientific result, but a
          > political one. How did you select your survey respondents?
          > Web surveys are self-selecting in their nature...
          >
          > > ... if you'd taken the time to [discuss your ideas] you would
          > > have learned something about the true message of the AM
          > > and AD communities.
          >
          > I think you need to consider Dan's "implications" as descriptions
          > of phenomena. IOW, they describe things he's seen. I've seen,
          > and successfully managed, most of them also. He's not talking
          > about ideas or responding to the "true message", but about
          > "what happens" with people who he thinks are trying to apply
          > Agile ideas. If you take the phenomenological view and assume
          > that the problems he describes really do occur (however loaded
          > may be the language he used to describe them), then you'll
          > learn something that will make the Agile position stronger.
          >
          > Firstly then, Agile does have a tendency to creating a greater
          > technical debt in regard to data models, by encouraging people
          > to expect that they can reduce the cost of refactoring below the
          > cost of BDUF. This may be true in some cases, but it's less true
          > of data models than for many other artefacts, and I've seen that
          > difference create pain. Refactoring data models is more painful
          > than people tend to expect (and more painful than it should be,
          > IMO), so they don't choose wisely when deciding where and
          > when to spend their effort. Our response here must be threefold:
          >
          > * Educate people about how to develop better data models,
          > * Educate people about the actual costs of refactoring data,
          > * Find ways to reduce the cost of refactoring data models.
          >
          > The failure of the data management community to properly
          > address any of these responses is one they must wear - it's
          > inexcusable. However, the underlying problem is that data
          > modeling is *hard* detailed work, not generally susceptible
          > to evolutionary approaches. The hard part isn't working out
          > what data items (elementary fact types) are needed, it's
          > working out how to aggregate them based on the principles
          > of normalisation. And when you add a single fact, or change
          > a single multiplicity constraint, the aggregation can change
          > radically - hence the extra cost of refactoring data. Also, to
          > delay thinking through the conceptual data model tends to
          > create poor design throughout the application, so the impact
          > is magnified (the Agile data community is addressing that).
          >
          > The response of the object-oriented community has been to
          > divide problems into regions of shared behaviour, which is a
          > less abstract approach, but creates different aggregations.
          > The difference is further magnified by the fact that object
          > modellers tend to think too much about the in-memory
          > representation of their data, and too little about the storage
          > aspects. Different aggregations are required because the
          > retrieval costs differ.
          >
          > The impedance between the two disciplines arises from this
          > difference, whether in a traditional model (throw a finished
          > O-O design "over the wall" to the DBAs and say "here, store
          > that!", or in an Agile model, where they're involved earlier.
          >
          > The right answer to the problems that occur on both sides of
          > this divide is to find ways to create and validate information
          > models *before* making any decisions about aggregation.
          >
          > That's what Object Role Modeling, or fact-based modeling does.
          > Information models created in this way are at a higher level
          > than either UML (and other object modeling approaches) or
          > traditional ER (entity-relationship) data modeling. It requires the
          > definition of conceptual information models that are "elementary",
          > meaning that every element (fact, rule and constraint) is broken
          > down to its simplest form, based in pure logic.
          >
          > With a model in elementary form, it's child's play to check its
          > correctness, as each feature can be verbalised in short plain-
          > language sentences as it's constructed. Example data may be
          > used for each fact type to allow automatic validation of constraints,
          > and even intuition about what missing constraints might have been
          > missed. It's possible to represent all constraint types that are
          > supported in both UML and in SQL, and quite a number that are
          > supported in neither, which gives the designer a greater power to
          > express business rules than either.
          >
          > After the model has been fully validated, tools can automatically
          > construct correct, efficient and fully normalized aggregations
          > (both class hierarchies and entity-relationship models) that are
          > provably congruent.
          >
          > I've been using this technique for more than twenty years and
          > I can't believe it hasn't taken off like wildfire, it's just so
          > effective.
          > I put that down to a lack of the right kind of tool support, and
          > that's the reason why I'm currently building some open source
          > tools that fill in some of the gaps. My approach doesn't entail
          > code generation like previous tools, but instead creates "executable
          > models". That means that each model is completely dynamic, which
          > makes it very suitable for an Agile approach. I've been sending
          > status announcements to the Yahoo group "information_modeling".
          > My software isn't ready for use yet, and I'm not writing to promote
          > them, but watch this space.
          >
          > In the meantime, I'd like to see some effective discussion of Object
          > Role Modeling. I truly believe it has the right answers here. I'll write
          > more about why if I get an interested response from these lists.
          >
          > Clifford Heath, Data Constellation.
          > Available for design consulting.
          >
          >
        • Jon Kern
          re: Firstly then, Agile does have a tendency to creating a greater technical debt in regard to data models, by encouraging people to expect that they can
          Message 4 of 11 , May 5, 2007
          • 0 Attachment
            re: " Firstly then, Agile does have a tendency to creating a greater
            technical debt in regard to data models, by encouraging people
            to expect that they can reduce the cost of refactoring below the
            cost of BDUF."

            Interesting supposition...

            Why does agile -- versus other processes -- cause greater technical
            debt? I appreciate the term <g>, but not sure if the cause is a given
            development process or just poor understanding of
            - development
            - data modeling
            - object modeling

            And possibly a poor understanding of the tradeoff of knowing how much to
            do up front to optimize use of resources versus doing a continuous poor
            job of thinking enough and thrashing the refactoring button on the IDE.

            I'm not quite sure why refactoring data models is any more costly than
            refactoring object models. My experience on doing new projects does not
            show data models to be any more or less expensive than other parts of
            the system. (Often GUIs are the gnarliest parts, but even they can be
            tamed.)

            jon
            blog: http://technicaldebt.com



            Clifford Heath said the following on 5/4/07 10:44 PM:
            >
            > Scott Ambler wrote in agilemodeling@yahoogroups.com
            > <mailto:agilemodeling%40yahoogroups.com>:
            > > Yikes.
            >
            > Scott,
            >
            > To some extent I share your strong feelings at the style of
            > Dan's presentation, but he has some valid points and I don't
            > think the manner of your response is doing you any favours.
            > A presentation like this needs to be punchy, and I don't see
            > the omission of attribution to be a serious problem; you're a
            > public figure, and anyone can Google up any of your quoted
            > statements and find the sources. To make insinuations about
            > copyright infringement is just plain childish. But enough about
            > that...
            >
            > You talk about "data management politicians" in your 2nd
            > response. In fact, such people generally act as bureaucrats.
            > Bureaucrats act as rule enforcers, whether the rules make
            > sense or not, and generally refrain from entering political
            > debates. Politicians OTOH act by persuading the public of
            > what rules and changes in the rules make sense. In this
            > sense you act as a politician - a laudable role. I think you
            > can see why I've characterised the groups this way. Perhaps
            > it's also part of the reason why they don't join your mailing
            > lists - it's too political for them and that personality type has
            > no taste for that - they prefer analysis to argumentation, and
            > rhetoric to dialectic. Nevertheless, we'll make more progress
            > the better the two groups collaborate, however hard that may
            > be.
            >
            > For that, I have some suggestions below - but first, I'll deal
            > with a couple of further issues arising from your responses.
            >
            > > BTW, my August
            > > column in DDJ will overview the results of a recent
            > > survey that we ran. The survey asked about the
            > > effectiveness of various development techniques,
            > > including both agile and traditional, and apparently
            > > in practice the agile techniques are measurably more
            > > effective. Details to come.
            >
            > Perhaps, but this is definitely not a scientific result, but a
            > political one. How did you select your survey respondents?
            > Web surveys are self-selecting in their nature...
            >
            > > ... if you'd taken the time to [discuss your ideas] you would
            > > have learned something about the true message of the AM
            > > and AD communities.
            >
            > I think you need to consider Dan's "implications" as descriptions
            > of phenomena. IOW, they describe things he's seen. I've seen,
            > and successfully managed, most of them also. He's not talking
            > about ideas or responding to the "true message", but about
            > "what happens" with people who he thinks are trying to apply
            > Agile ideas. If you take the phenomenological view and assume
            > that the problems he describes really do occur (however loaded
            > may be the language he used to describe them), then you'll
            > learn something that will make the Agile position stronger.
            >
            > Firstly then, Agile does have a tendency to creating a greater
            > technical debt in regard to data models, by encouraging people
            > to expect that they can reduce the cost of refactoring below the
            > cost of BDUF. This may be true in some cases, but it's less true
            > of data models than for many other artefacts, and I've seen that
            > difference create pain. Refactoring data models is more painful
            > than people tend to expect (and more painful than it should be,
            > IMO), so they don't choose wisely when deciding where and
            > when to spend their effort. Our response here must be threefold:
            >
            > * Educate people about how to develop better data models,
            > * Educate people about the actual costs of refactoring data,
            > * Find ways to reduce the cost of refactoring data models.
            >
            > The failure of the data management community to properly
            > address any of these responses is one they must wear - it's
            > inexcusable. However, the underlying problem is that data
            > modeling is *hard* detailed work, not generally susceptible
            > to evolutionary approaches. The hard part isn't working out
            > what data items (elementary fact types) are needed, it's
            > working out how to aggregate them based on the principles
            > of normalisation. And when you add a single fact, or change
            > a single multiplicity constraint, the aggregation can change
            > radically - hence the extra cost of refactoring data. Also, to
            > delay thinking through the conceptual data model tends to
            > create poor design throughout the application, so the impact
            > is magnified (the Agile data community is addressing that).
            >
            > The response of the object-oriented community has been to
            > divide problems into regions of shared behaviour, which is a
            > less abstract approach, but creates different aggregations.
            > The difference is further magnified by the fact that object
            > modellers tend to think too much about the in-memory
            > representation of their data, and too little about the storage
            > aspects. Different aggregations are required because the
            > retrieval costs differ.
            >
            > The impedance between the two disciplines arises from this
            > difference, whether in a traditional model (throw a finished
            > O-O design "over the wall" to the DBAs and say "here, store
            > that!", or in an Agile model, where they're involved earlier.
            >
            > The right answer to the problems that occur on both sides of
            > this divide is to find ways to create and validate information
            > models *before* making any decisions about aggregation.
            >
            > That's what Object Role Modeling, or fact-based modeling does.
            > Information models created in this way are at a higher level
            > than either UML (and other object modeling approaches) or
            > traditional ER (entity-relationship) data modeling. It requires the
            > definition of conceptual information models that are "elementary",
            > meaning that every element (fact, rule and constraint) is broken
            > down to its simplest form, based in pure logic.
            >
            > With a model in elementary form, it's child's play to check its
            > correctness, as each feature can be verbalised in short plain-
            > language sentences as it's constructed. Example data may be
            > used for each fact type to allow automatic validation of constraints,
            > and even intuition about what missing constraints might have been
            > missed. It's possible to represent all constraint types that are
            > supported in both UML and in SQL, and quite a number that are
            > supported in neither, which gives the designer a greater power to
            > express business rules than either.
            >
            > After the model has been fully validated, tools can automatically
            > construct correct, efficient and fully normalized aggregations
            > (both class hierarchies and entity-relationship models) that are
            > provably congruent.
            >
            > I've been using this technique for more than twenty years and
            > I can't believe it hasn't taken off like wildfire, it's just so
            > effective.
            > I put that down to a lack of the right kind of tool support, and
            > that's the reason why I'm currently building some open source
            > tools that fill in some of the gaps. My approach doesn't entail
            > code generation like previous tools, but instead creates "executable
            > models". That means that each model is completely dynamic, which
            > makes it very suitable for an Agile approach. I've been sending
            > status announcements to the Yahoo group "information_modeling".
            > My software isn't ready for use yet, and I'm not writing to promote
            > them, but watch this space.
            >
            > In the meantime, I'd like to see some effective discussion of Object
            > Role Modeling. I truly believe it has the right answers here. I'll write
            > more about why if I get an interested response from these lists.
            >
            > Clifford Heath, Data Constellation.
            > Available for design consulting.
            >
            >
          • Clifford Heath
            I m going to respond to this only in information_modeling, for the benefit of any others who might be interested. Clifford Heath.
            Message 5 of 11 , May 5, 2007
            • 0 Attachment
              I'm going to respond to this only in information_modeling,
              for the benefit of any others who might be interested.

              Clifford Heath.
            • Willem Bogaerts
              ... Well, it is not REALLY wrong. The agile way is to start with only a tiny fraction and let it grow. Seen from the traditional standpoint, there is a
              Message 6 of 11 , May 7, 2007
              • 0 Attachment
                > re: " Firstly then, Agile does have a tendency to creating a greater
                > technical debt in regard to data models, by encouraging people
                > to expect that they can reduce the cost of refactoring below the
                > cost of BDUF."
                >
                > Interesting supposition...

                Well, it is not REALLY wrong. The "agile way" is to start with only a
                tiny fraction and let it grow. Seen from the traditional standpoint,
                there is a technical debt of 90% if you only implemented and designed
                the first 10%.
                The difference, off course, is that agilists do not believe that the
                other 90% in a BDUF is NOT a technical debt.

                Best regards,
                --
                Willem Bogaerts

                Applicatiesmid
                Kratz B.V.
                http://www.kratz.nl/
              • Curt Sampson
                ... I think I m now beginning to understand, on a deeper level, why people would object to some of this agile stuff. From my agile point of view, that other
                Message 7 of 11 , May 7, 2007
                • 0 Attachment
                  On Mon, 7 May 2007, Willem Bogaerts wrote:

                  > The "agile way" is to start with only a tiny fraction and let it grow.
                  > Seen from the traditional standpoint, there is a technical debt of 90%
                  > if you only implemented and designed the first 10%. The difference,
                  > off course, is that agilists believe that the other 90% in a BDUF is
                  > NOT a technical debt.

                  I think I'm now beginning to understand, on a deeper level, why people
                  would object to some of this agile stuff.

                  From my agile point of view, that other 90% certainly IS a technical
                  debt. But let's extend the analogy.

                  Debts have a couple of interesting characteristics. The simpler one is
                  that they're based on past characteristics, and things change. So the
                  actual cost to pay a debt can go down or up in the future, independent
                  of the original commitment. For example, if I'm earning money in yen (as
                  I am, since I live in Japan), and I owe you a United States dollar, if I
                  paid you today, it would cost me 121.04 yen to pay you that dollar. But
                  it could well be that, if I paid you a week from now, it would cost me
                  only 118 yen to pay you that dollar, due to exchange rate fluctuations.
                  Even if I'm paying interest on that dollar, it may still cost me less to
                  pay you $1.02 in a week than it would cost me to pay you a dollar today.

                  More importantly, the interest I'm paying on a debt is quite important.
                  Usually you can borrow money at a higher rate than you can lend it at.
                  (That's how banks and market-makers make money.) If at the time I incurr
                  a debt, the prime rate is 5%, I might make a contract with you to borrow
                  at 5.3%. If, in a while, the prime rate increases to 6%, and I come into
                  enough money to pay off that entire debt right away, should I pay it?
                  No; I should maintain the debt, lend my newfound money at at 5.6%, and
                  continue paying you 5.3% interest; I'll make more money that way than I
                  would in the savings on interest charges if I paid off the whole debt to
                  you right now.

                  In the world of software construction, the equation is quite dramatic.
                  It continually gets cheaper and cheaper to write the same functionality,
                  because as time passes computers become faster (enabling the use of
                  less efficient but quicker-to-write algorithms), you have better
                  libraries available, and you have more experience. Agile methods
                  gain advantage from this this fact of computer life by delaying both
                  design and implementation as long as possible, so that the design and
                  implementation can take advantage of the newer and cheaper technology
                  that's become available when you get around to implementing some
                  particular thing.

                  The most dramatic example, of course, is when you owe someone something
                  large and they decide that they don't want it any more; if you built it,
                  you lose; if you didn't build it, you win. This happens surprisingly
                  often.

                  In both the financial world and the computer world, this sort of
                  behaviour and strategy makes naive folks quite nervous; to them the
                  risks look much higher than they really are. But if you sit down and
                  really do the math, it works.

                  Really, I think that this is a great time to be an agilist. It's
                  mainstream and accepted enough that you've got no real problem selling
                  the strategy, yet there's still not a huge amount of competition because
                  not enough people and projects have had their lunch eaten by agilists
                  that everybody and his brother is doing it, and making competition much
                  more difficult.

                  I can see agile moving forward, year by year; some folks are making
                  really good progress into bringing agile technology into embedded
                  systems, for example. Yet the case against agile doesn't seem to
                  have advanced beyond Stephens and Rosenberg's _Extreme Programming
                  Refactored: The Case Against XP_ (which is nearing its fourth
                  aniversary). (I also find it ironic that Amazon's "Better Together"
                  recommendation pairs this with the new version of Kent Beck's _Extreme
                  Programming Explained: Embrace Change_.) The anti-agile crowd is still
                  at the level of "this can't work because..." rather than "here's
                  something that seems to be working better."

                  Anyway, carry on. I look forward to your article or book on what you're
                  doing now that you weren't doing five years ago that's increased your
                  productivity.

                  cjs
                  --
                  Curt Sampson +81 90 7737 2974
                  <cjs@...> http://www.starling-software.com
                  The power of accurate observation is commonly called cynicism
                  by those who have not got it. --George Bernard Shaw
                Your message has been successfully submitted and would be delivered to recipients shortly.