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

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

Expand Messages
  • 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 1 of 18 , Jan 6, 2010
    • 0 Attachment
      >
      > > 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 2 of 18 , Jan 9, 2010
      • 0 Attachment
        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 3 of 18 , Jan 9, 2010
        • 0 Attachment
          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.