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

Re: [XP] is XP adapted for Business Intelligence applications

Expand Messages
  • Ron Jeffries
    Hello, JeffGrigg. On Tuesday, January 5, 2010, at 8:02:21 AM, you ... Me too, and I m not aware of any moderation (on my part). Did you say F#$% or something?
    Message 1 of 18 , Jan 5, 2010
      Hello, JeffGrigg. On Tuesday, January 5, 2010, at 8:02:21 AM, you
      wrote:

      > [After all these years, it does seem that my posts are now
      > moderated. How interesting. I do think that my contributions are constructive.]

      Me too, and I'm not aware of any moderation (on my part). Did you
      say F#$% or something? :)

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      If it is more than you need, it is waste. -- Andy Seidl
    • JeffGrigg
      ... No. But I might, if it takes several days to post a message! ;- Perhaps my previous posts just got lost in some bit-bucket. Bother!
      Message 2 of 18 , Jan 5, 2010
        --- John Roth <JohnRoth1@...> wrote:
        > I've seen some messages take as long as a couple of days to
        > clear whatever process Yahoo uses, and it's been going on for
        > several months.

        --- Ron Jeffries <ronjeffries@...> wrote:
        > Me too, and I'm not aware of any moderation (on my part).
        > Did you say F#$% or something? :)

        No. But I might, if it takes several days to post a message! ;->

        Perhaps my previous posts just got lost in some bit-bucket. Bother!
        :-[
      • D.AndrĂ© Dhondt
        ... In my experience with DSS and T-SQL, TDD doesn t make a lot of sense for a 4GL like SQL, which doesn t really specify what we re going to do in a unit way.
        Message 3 of 18 , Jan 6, 2010
          >
          > > That said, it is certainly possible to do TDD for procedural
          > > code including PL/SQL.
          >

          In my experience with DSS and T-SQL, TDD doesn't make a lot of sense for a
          4GL like SQL, which doesn't really specify what we're going to do in a unit
          way. We added tests, but they don't have the same kind of coverage as UTs.
          Scaled-down dev/test databases don't make much sense either, since we
          didn't really know what records the query was going to fetch, nor what the
          performance implications would be, until we ran it in the production
          environment. Even the execution paths turned out different on tables with
          different statistics.

          One of the aims of TDD is to make sure our units are right--that they are
          what we intended. What we found is that by using smaller chunks, e.g.,
          'extracting method' in our server-side code as much as possible, we
          clarified our intent, we could add some integration tests/functional
          tests/FIT tests, and basically we got more confidence in our database-side
          code. We also found that by clarifying intent, we could simplify the
          existing code, and that made significant gains in performance. Regression
          testing was almost entirely manual, though.

          Still, the biggest concern with db-side changes had to do with performance,
          and we just couldn't find a way to provide sufficient test coverage for
          that. So our strategy (there is a book written on this subject, db
          refactoring or something, but I never read it) ended up being a strangler
          pattern--isolate the functionality that needed to be on the database, add
          some functional tests, and then just don't touch it unless it's important
          enough to test on the production servers....





          --
          D. André Dhondt
          mobile: 001 33 671 034 984
          http://dhondtsayitsagile.blogspot.com/

          Support low-cost conferences -- http://agiletour.org/
          If you're in the area, join Agile Philly http://www.AgilePhilly.com
          Mentor/be mentored: the Agile Skills Project
          https://sites.google.com/site/agileskillsprojectwiki/


          [Non-text portions of this message have been removed]
        • Phlip
          ... This is why one Ward Cunningham just tweeted Estimating is the non-problem that know-nothings spent decades trying to solve. I would have been more
          Message 4 of 18 , Jan 9, 2010
            loicmidy wrote:

            > Our current methodology is faterfall. Here are ours main problems with it:
            > 1 : we have a long study phase at the beginning of each project : between 1 year and 1 year and a half. Consequences : the duration of the project is long + the managers like me have little visibility during this phase. I hope to slash this phase to 6 month at maximum.
            > 2 : our customer are our statisticiens and they often ask for features that in fact they don't nead (we see that in the end). By giving frequent feedback to ours statisticiens and by prioritizinf features I hope we won't developp useless features.

            This is why one Ward Cunningham just tweeted "Estimating is the non-problem that
            know-nothings spent decades trying to solve."

            I would have been more gentle to your waterfallers...
          • Adam Sroka
            ... Yeah. I had to retweet that one myself. ... I sat in on a meeting yesterday (Fri) where one of the teams my colleague is coaching was trying to understand
            Message 5 of 18 , Jan 9, 2010
              On Sat, Jan 9, 2010 at 10:14 PM, Phlip <phlip2005@...> wrote:
              >
              >
              >
              > loicmidy wrote:
              >
              > > Our current methodology is faterfall. Here are ours main problems with it:
              > > 1 : we have a long study phase at the beginning of each project : between 1 year and 1 year and a half. Consequences : the duration of the project is long + the managers like me have little visibility during this phase. I hope to slash this phase to 6 month at maximum.
              > > 2 : our customer are our statisticiens and they often ask for features that in fact they don't nead (we see that in the end). By giving frequent feedback to ours statisticiens and by prioritizinf features I hope we won't developp useless features.
              >
              > This is why one Ward Cunningham just tweeted "Estimating is the non-problem that
              > know-nothings spent decades trying to solve."
              >

              Yeah. I had to retweet that one myself.

              > I would have been more gentle to your waterfallers...
              >

              I sat in on a meeting yesterday (Fri) where one of the teams my
              colleague is coaching was trying to understand how to estimate. It was
              very painful. I made the point that they needed to do their best
              according to what they already seemed to understand, that their
              estimates would still be wrong, but that it would all work out over
              time. They looked at me like I was speaking some alien language (Which
              I suppose isn't far from the truth.)

              >
            Your message has been successfully submitted and would be delivered to recipients shortly.