Wednesday, November 16, 2011

How to mothball a project

Part of the reason that the last several posts I've made since I returned from my hiatus have not been obviously related to the DBFSpy project that I started this blog with is that in the intervening couple of months, I've forgotten a lot of what I'd intended to do with it.

Fortunately, I had documented at least a sequence of classes, interfaces, etc., that I'd expected to cover, so it's not like I'm completely lost. At the same time, though, I hadn't gotten even as far as stubbing out properties and methods for the remaining items before things got out of control, and I had no time to continue posting.

When projects are in danger of needing to be mothballed, I like to try and spend as much time as I can get away with making sure that I capture as much of my thought-process as I can before I have to set it aside. I don't always get as much of this kind of time as I'd like, though, even when the project in question is my own.

Case in point: All I really have on DBFSpy is a list of classes and interfaces I was expecting, and some indication that they were nominally complete (though maybe not with full unit-tests, etc.):
  • BaseDatabaseConnection (abstract class, complete)
  • BaseDataObject (abstract class, complete)
  • BaseFileSystemItemCache (abstract class, complete)
  • IFilesystem (interface, complete)
  • IFilesystemItem (interface)
  • IFileystemOperators (interface)
  • MySQLDatasource (class)
  • MySQLFileItem (class)
  • MySQLFilesystem (class)
  • Unit-tests for classes, etc.
  • dbfspy (executable)
Looking at older posts here, it looks like I was about on track with this list. I also managed to create and post the UML diagram, which I hope will refresh my memory somewhat as I start digging into that project again. Though now I suspect I'll need to review my progress (it looks like I had to break off after IFilesystem, bu before IFilesystemItem). With some luck, given my new insights into testing, and the discovery of properties and methods that it facilitates, I'll be able to recapture a lot of my previous momentum, and bang things out quickly. If not, I guess I'll have to think about either setting it aside again (with the expectation that it'll be so full of holes by the time I pick it up again that I'll be starting from scratch), or just biting that bullet now, and re-starting.

So, chalk this up to another lesson learned - take the time to document and comment as you go. You never know when you may have to set a project aside, and if there isn't time to gracefully (and thoroughly) mothball it, it may very well be full of holes by the time you get back to it.

What I think I'd advocate is (at the very least):
  • Make sure all decisions are documented;
  • If possible, make sure that any class-diagrams are complete as of the time the project had to be stopped;
  • Make sure that the design is thorough, documented, and annotated as needed to keep track of what the design intended to achieve, and what modifications had to be made, if any.
There may be other items as well, but these are, I hope, the major items...

Another part of the reason I spent the last few posts going over new stuff (apart from my enthusiasm for the topic therein), was that as I was working through a Python project at work, it occurred to me that it might be a cool idea to generate a small, freestanding, Python-based web-application server framework. Nothing huge, you understand, but rather something that could be incorporated into other Python projects, to allow for things like administrative interfaces for services and the like.

More on that topic later, I think...

No comments:

Post a Comment