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

Building Confidence in the Code and Making More Frequent Releases

Expand Messages
  • Shlomi Fish
    Hi all! I am the originator and maintainer of Freecell Solver ( http://fc-solve.berlios.de/ ) which is an open-source library. Now until version 2.8.x, I did
    Message 1 of 3 , Mar 31, 2009
    • 0 Attachment
      Hi all!

      I am the originator and maintainer of Freecell Solver (
      http://fc-solve.berlios.de/ ) which is an open-source library. Now until
      version 2.8.x, I did not have any organised automated tests and the library
      used a complex, idiosyncratic Autoconf/Automake/Libtool-based configuration
      and build process.

      My methodology of working on the library consisted of working on the library
      for weeks, or even months at a time, enhancing and refactoring it, with many
      bugs being discovered and fixed, and after all that releasing a new stable $x.
      $y.0 release (where $y is even - like the old Linux kernel scheme). And if it
      wasn't enough, I usually released a few bug fix $x.$y.1, $x.$y.2, etc.
      releases to the stable release.

      However, lately I've been investing only a few days of work between stable
      releases, they are new $x.$y.0 releases with new enhancements, and there are
      no bug fixes releases. I already had six consecutive .0 releases.

      I think several factors contributed to it:

      1. I converted from using no version control at all to CVS and then to
      Subversion ( http://subversion.tigris.org/ ). The latter provides a much
      better way to manage the code, and have confidence in not losing anything.

      2. I converted the config+build system from GNU Autoconf and friends (a.k.a
      GNU Autohell) to http://www.cmake.org/ . As a result, I got much faster build
      times, much less headache in maintaining it. It now proved itself usable for
      day-to-day development use and as a result ditched my "make -f Makefile.gnu"
      scheme, and switched to using CMake for development.

      3. Using valgrind ( http://valgrind.org/ ) has resulted in much fewer memory
      errors, smoother debugging and more confidence in the integrity of the code.

      4. And the most important reason - I added a test suite. It's not very big at
      the moment, and only takes about a minute to run, but it still can tell me
      that I've broken something, more often than not. As a result, I have much more
      confidence in the integrity of my code when the test passes, and know that
      something is wrong when they don't.

      --------------------

      All of this confidence has resulted in me being able to make more frequent
      stable releases of Freecell Solver, all with incremental improvements.
      Usually, if a bug fix is considered for a stable release, then I can just
      correct it on the Subversion trunk, and release a new stable release with it
      and other improvements shortly afterwards.

      I love being able to make such frequent releases, and it's all thanks to the
      increased confidence I have in the integrity of the code, thanks to the test
      suite and use of better tools.

      Regards,

      Shlomi Fish

      --
      -----------------------------------------------------------------
      Shlomi Fish http://www.shlomifish.org/
      First stop for Perl beginners - http://perl-begin.org/

      God gave us two eyes and ten fingers so we will type five times as much as we
      read.
    • Olof Bjarnason
      2009/3/31 Shlomi Fish ... Thanks for sharing your story! ... -- Min blogg: http://olofb.wordpress.com [My blog, in Swedish]
      Message 2 of 3 , Mar 31, 2009
      • 0 Attachment
        2009/3/31 Shlomi Fish <shlomif@...>
        >
        > Hi all!
        >
        > I am the originator and maintainer of Freecell Solver (
        > http://fc-solve.berlios.de/ ) which is an open-source library. Now until
        > version 2.8.x, I did not have any organised automated tests and the library
        > used a complex, idiosyncratic Autoconf/Automake/Libtool-based configuration
        > and build process.
        >
        > My methodology of working on the library consisted of working on the library
        > for weeks, or even months at a time, enhancing and refactoring it, with many
        > bugs being discovered and fixed, and after all that releasing a new stable $x.
        > $y.0 release (where $y is even - like the old Linux kernel scheme). And if it
        > wasn't enough, I usually released a few bug fix $x.$y.1, $x.$y.2, etc.
        > releases to the stable release.
        >
        > However, lately I've been investing only a few days of work between stable
        > releases, they are new $x.$y.0 releases with new enhancements, and there are
        > no bug fixes releases. I already had six consecutive .0 releases.
        >
        > I think several factors contributed to it:
        >
        > 1. I converted from using no version control at all to CVS and then to
        > Subversion ( http://subversion.tigris.org/ ). The latter provides a much
        > better way to manage the code, and have confidence in not losing anything.
        >
        > 2. I converted the config+build system from GNU Autoconf and friends (a.k.a
        > GNU Autohell) to http://www.cmake.org/ . As a result, I got much faster build
        > times, much less headache in maintaining it. It now proved itself usable for
        > day-to-day development use and as a result ditched my "make -f Makefile.gnu"
        > scheme, and switched to using CMake for development.
        >
        > 3. Using valgrind ( http://valgrind.org/ ) has resulted in much fewer memory
        > errors, smoother debugging and more confidence in the integrity of the code.
        >
        > 4. And the most important reason - I added a test suite. It's not very big at
        > the moment, and only takes about a minute to run, but it still can tell me
        > that I've broken something, more often than not. As a result, I have much more
        > confidence in the integrity of my code when the test passes, and know that
        > something is wrong when they don't.
        >
        > --------------------
        >
        > All of this confidence has resulted in me being able to make more frequent
        > stable releases of Freecell Solver, all with incremental improvements.
        > Usually, if a bug fix is considered for a stable release, then I can just
        > correct it on the Subversion trunk, and release a new stable release with it
        > and other improvements shortly afterwards.
        >
        > I love being able to make such frequent releases, and it's all thanks to the
        > increased confidence I have in the integrity of the code, thanks to the test
        > suite and use of better tools.

        Thanks for sharing your story!

        >
        > Regards,
        >
        > Shlomi Fish
        >
        > --
        > ----------------------------------------------------------
        > Shlomi Fish http://www.shlomifish.org/
        > First stop for Perl beginners - http://perl-begin.org/
        >
        > God gave us two eyes and ten fingers so we will type five times as much as we
        > read.
        >
        >


        --
        Min blogg:
        http://olofb.wordpress.com
        [My blog, in Swedish]
      • Tim Ottinger
        Thanks for a small success story. Tim Ottinger http://agileinaflash.blogspot.com/ http://agileotter.blogspot.com/
        Message 3 of 3 , Apr 1, 2009
        • 0 Attachment
          Thanks for a small success story.

          Tim Ottinger
          http://agileinaflash.blogspot.com/
          http://agileotter.blogspot.com/
        Your message has been successfully submitted and would be delivered to recipients shortly.