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

155732Re: [XP] INVEST stories and estimations

Expand Messages
  • Dave Rooney
    Sep 30, 2010
    • 0 Attachment
      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
    • Show all 14 messages in this topic