Presenting Early and Often

Shout out and thanks to Robert Howley for his compliment on the session I presented in yesterday morning on Open Source Solvers and Modeling Languages.  We’ll cherish the award.  Robert’s comments and John Angelis’s entry on half-baked ideas prompted some reflections on where the work I presented is and how it came to be there.

There’s a principle in open-source software development: Release early, release often.  The idea is that if you release something useful, even if it isn’t “feature complete”, you can attract users to your community and get feedback.  If you release often, users can take advantage of new features and bug fixes as soon as they are ready, and you get even more feedback.

We are working on the COIN-OR Open Solver Interface (OSI).  OSI was one of the four original projects when COIN-OR debuted at MPS in the summer of 2000.  Its objective was to provide a “solver-agnostic” API for programmers using callable libraries such as CPLEX, OSL, XPRESS, and the COIN-OR volume algorithm package  to solve LPs.  It sort of achieved that objective, but with experience, we realized it was awkward to use and awkward to extend.  It took very little time for us to start thinking about redesigning it from the ground up.

Over the course of a couple of years and several INFORMS meetings (in those days, the spring and fall meetings had the same format), I presented several iterations of a proposed redesign.  As I developed the plan,  implemented test ideas, and (importantly)received feedback from my audiences and others,  I came to believe that the design didn’t really address some of the key concerns.  Finally, I dropped the project.

Last year, after leaving it alone and after improving my knowledge of C++ and object-oriented design, Lou Hafer and I started to rethink the problem again, with a fresh approach. We presented the basic idea at INFORMS2010 and reported our progress here.  Between our own thoughts and the feedback we’ve received, we are fairly confident that this time, we have the right set of abstractions.

The point here is that we have used this meeting to present ideas at very early stages of development and we’ve been able to leverage the experience to improve our work.  Not every meeting is as amenable as this one to this purpose, though, and John raises some issues that really weren’t big concerns for us.  Nevertheless, I think early dissemination of ideas is useful and the INFORMS Annual Meetings are underappreciated and underutilized for this purpose.