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

155752Re: [XP] INVEST stories and estimations

Expand Messages
  • Stephan Huez
    Oct 1 6:50 AM
      Hi Dave,

      Thanks for the example. They are very illustrative. I especially notice that
      the domain had become mature by the time you moved towards a database.

      Kind regards,


      On 30 September 2010 15:56, Dave Rooney <dave.rooney@...> wrote:

      > On 30/09/2010 9:29 AM, Chet Hendrickson wrote:
      > > The need for the database should arise from the stories the Customer
      > > is naturally bringing to the team. If it doesn't, well then...
      > Two concrete examples:
      > 1) A system that simply used flat files to persist user data (Java
      > properties files). A story came along that required tracking usage data
      > for the system, i.e. where a user went and how long they spent on that
      > page. No problem, the flat file solution continued to work. Another
      > story came along shortly thereafter that asked for reporting based on
      > that usage data. In order to implement the story, we would have to pull
      > data from a number of flat files and, well, flat files are somewhat
      > difficult to use in a relational manner. That story became the catalyst
      > to use a relational database. What was good, though, was that the
      > domain model was mature at that point, and changing the persistence
      > mechanism to use Hibernate and MySQL was relatively straightforward and
      > only took a few days.
      > 2) Another system in which I used a similar approach to #1 - originally
      > data was persisted as serialized Java classes. That was fine for an
      > initial release, but became problematic as changes were requested. So,
      > I changed the persistence to use XML via XStream. That worked well and
      > proved much more flexible. Then along came a story that again required
      > usage metrics and the need to relate data from several places. Again, I
      > changed the persistence mechanism to use Hibernate and MySQL over a
      > couple of days and the mature domain model meant that there were very
      > few DB changes needed after that point.
      > In both systems, each persistence mechanism was the simplest possible at
      > the time it was implemented. Each change to a new mechanism only took a
      > short time, and it was performed at the proverbial 'last responsible
      > moment'. In all cases, it was a business requirement that drove the
      > technical need to change the persistence mechanism.
      > --
      > Dave Rooney
      > Westboro Systems
      > Web: http://www.WestboroSystems.com
      > Blog: http://practicalagility.blogspot.com
      > Twitter: daverooneyca

      Stephan Huez
      Blog: http://softwareinabottle.wordpress.com/

      [Non-text portions of this message have been removed]
    • Show all 14 messages in this topic