March 2010

The first version (0.1.0) of The MiniMiser Framework is now available, and work progresses on 0.2.0.

See the project home page for more details!


Note: this post was written some time ago, but wasn’t published then – the figures for lines of Java are now: 59416 (main: 31737; test: 27759), 649 tests with 70.1% coverage – the first ‘0.1.0’ release.

One of the tenets of Open Source development is “Release early, release often” (see The Cathedral and the Bazaar); another is “If you build it, they will come” (not sure where this came from – it’s in Field of Dreams…).

I work from slightly different versions of these: Release quality first, then release it often. If you build the code, then you have to build the community, then they come.

I could have created a public repository somewhere (SourceForge? BitBucket? GitHub?) and committed the very first lines of code, allowing developers to keep up with the early progress of the application, but I chose not to. Instead, I’ve spend a year and a half developing on my own, not making the code available. It still isn’t available, nor will it be, until it’s ready. Until it has reached some level of maturity and works as I intend; until it’s sufficiently complete, and until it has ‘quality’ (whatever that is; I’m trying to define it in another post). I’ve seen way too many Open Source projects falter after releasing too early: I want to ensure that the project is viable for myself before I expect others to judge it or use it.

An analogy might help me defend this position: I play guitar and keyboards (occasionally), but I don’t like others listening to me practice. I’d rather perfect my technique and give a performance when I’m good enough. Some players don’t mind others listening to their duff notes and bad timing; I’d rather not inflict that on others.

Likewise, with the code, I think it’s better to let me refactor it into the cleanest, highest-quality, most understandable, tested and testable design that does what it was intended to do first, before letting others loose on it.

Sure, I miss out on early feedback, and now, there’s a lot of code for people to work with and give feedback on (which could be grossly negative, however, I think I’ve got a good design, so that this won’t be the case). The codebase is currently standing at 47,464 lines of Java code in total, that’s 25,207 LOC main code, 22,257 LOC unit/integration test code – 580 tests in all.

However, I’d rather spend the time completing the architecture; I’ve got ideas to express that I need to get down in tests and code – then, I’ll take it all public. I definitely don’t want design by committee at this early stage. I might release a few “technology preview” versions though, if only to get the release mechanism in place – Paul Graham said it best:

In the desktop software business, doing a release is a huge trauma, in which the whole company sweats and strains to push out a single, giant piece of code. Obvious comparisons suggest themselves, both to the process and the resulting product.

— “Hackers and Painters, p62”

He’s talking about the difference between installed software and web-based, server-deployed software, but his point about releases of desktop software is valid: it takes a lot of infrastructure buildup, testing and polish.

One working definition of quality for this project is that the code should be free from internal contradictions (Christopher Alexander, quoted in Richard Gabriel, Patterns of Software, p35, – and having one developer define the architecture helps in this – there’s a single vision; I don’t have to work against several different aspects of the system at once, or mentor others who may be working in different areas (perhaps this is a trust / delegation issue?) thereby allowing me the time to get things to the state I want them in. Fred Brooks’ suggests, for the size of the team and the creative force:

Ten people, seven of them professionals, are at work on the problem, but the system is the product of one mind – or at most two, acting uno animo.

(The Mythical Man-Month, 20th Anniversary Ed, p35)

A view against my stance was recently posted by chromatic in his excellent “Modern Perl Books” blog:

I’ve written before that rapid, feedback-aware iteration is an effective way to understand a problem and find working solutions. Feedback from real users with real uses is invaluable (see also why Pugs and, later, Rakudo multiplied the velocity of Perl 6). You won’t understand the problem fully until you’ve had to balance multiple, sometimes contradictory, constraints. Just as no battle plan survives contact with the enemy, no software design survives contact with users unscathed. You may find that you’re painting yourself into a corner.
There’s a balance: you don’t want to cause users unnecessary pain by rapid, arbitrary change, but legacy code and features can hamstring a project.

– from Designing for the Unanticipated

So I could be “painting myself into a corner” by not releasing until it’s ready. However, perhaps even with the amount of code I have already, it’s still to early to release – it doesn’t do what it’s intended to do, yet.

Once I cut that first release, then I’ll release often. I prefer “Release quality, release often”. Then I’ll see whether they’ll come after something usable’s built.