Tuesday, September 27, 2011

StudyStreams will live, dammit.

I've been reading Joel on Software some more, and by the time I reached this, I decided I really do want to get StudyStreams out there.  Maybe because it seemed like a great idea at the time, or maybe because it feels like something I can actually complete (and I still think I can:  not very quickly, but I think it's possible), or maybe just because I feel bad for starting something, intending to finish it, and never getting around to it.

I've signed up for FogBugz yesterday, and I've been pleased with it so far.  As a student, I have the chance to use it for free (yay!).  I have considered using it for StudyStreams, but I don't think it's quite worth it; the system seems oriented to a set team of developers who interact heavily, and while it provides some awesome features (like built-in time estimates that tell you when you're likely to be finished), I just don't think it'll work well with an open source project.

I still feel the need to talk about it because I've been reading about it lots and was excited to try it because playing around with it made me realise just how much easier developing would be if I always had a clear idea of what I need to do, how much time I estimated it would take, and when I intended to finish it.  I've used some issue tracking on StudyStreams, but it was mostly a matter of Notice Improvement -> Check Whether Reasonable -> Implement Improvement, with only very major and global issues being reported.  After coding for some time, with two or three (possibly unrelated) improvements done, I'd commit and move on.

I'm now going to try to use the powers of issue tracking systems and my greatly reduced coding time to improve StudyStreams as much as possible, and then release it.  I don't care if I won't have users.  I don't care if some part of the design is suboptimal.  I want an archive that I can point people to, and say ``Hey, if you want to try StudyStreams, just extract this and run the install script''.

In order to do this, I'm going to do commit to the following things:
  • Every week, I will spend one hour looking at StudyStreams code, writing documentation, and submitting issues as necessary.
  • Also, every week, I will spend two hours coding StudyStreams.   I will choose a bug to fix or a feature to implement, then work only on that bug or feature (reporting any other changes I may realise are a good idea), and committing each time I finish a single report.
  • Every issue will have an estimate with the time necessary attached, and I will report the time taken when I close it.
  • No features will be added after 2011.10.31 (October 31st, 2011).
  • The archive I mentioned before will be ready and uploaded by 2011.11.14 (November 14th, 2011).
  • For completeness' sake:  the archive will consist of the source code of the StudyStreams framework, the lessons, a build system for the lessons, and a general build system that allows installation on Linux.
  • If one of the build systems is missing, or if there are too few lesson:  boo hoo, too bad, I will release it anyway with instructions for compiling manually, or with instructions on how to write your own lessons, whichever applies.
The last point may be questionable, but I suspect it's easier to write tutorials for released code than for unreleased code.  The pathetic attempt at a tutorial that my spec for a while was became outdated between the time I wrote it and the time I saved it -- that's the time it took to notice a minor `improvement' that could be made.  Hopefully, if I have a version to write to (instead of writing to the latest revision, as I was doing so far), I'll be able to produce something that people will be able to follow.

To finish off, I think the most limiting factor that I have had so far in terms of releasing is the idea that the lesson interface has to be finished before the first release.  This is, as I now realise, wrong.  I don't know why it took so long to get it, but being afraid that someone will use my software and then be unhappy if I change the interface is plain out ridiculous.  Apart from the tiny chance of release 0.1 getting a single lesson-writer, there's also the fact that if a there really was a user, it would mean I could get some feedback on the interface and therefore make a more informed decision on whether it would be a good idea to change it.  The juggling of squares on a diagram may be interesting, but I won't know which works better in practice from that.

So, now that I've rambled on about this, I'll be off to put all this into the issue tracker.

No comments:

Post a Comment