We've crossed a huge milestone this past week. fmSpark 1.0 is officially in private BETA and I thought I'd step back a little and get you all caught up on the development effort.

First, a huge thanks to the those who have been using version 0.9 in production work, and also to John Sindelar at SeedCode for the tremendous positive prodding a long the way.

Here are some raw stats on our development experience in the last few months. We've logged and resolved over 210 issues between versions 0.9 and 1.0. These include 80-something bona-fide bugs, nearly 70 feature improvements and a dozen or so new features. We've burned over 500 hours in development time and too many cups of coffee to track.

This is going to be a big release.

I had originally wanted fmSpark 1.0 out the door in January of this year, but we just weren't too happy with some lingering questions. In particular, we've been putting off the ugly business of scrubbing and organizing our scripts and fmSpark 1.0 was just begging for some TLC in that department. It was starting to feel like the sprawling suburbs of Jacksonville.

Stuffing more scripts into more folders and subfolders simply made the things worse. The scriptmaker window was getting scary and feeling clunky and difficult to understand. We needed a framework to avoid tripping over each other--the old lemme-just-write-my-own-version-of-your-script-because- i-am-not-sure-what-it-does way of collaboration.

Believe me when I say there was a lot of pressure to just ship it in a "good-enough" state and worry about making it "better" later, but we really felt it was important that this revision of fmSpark feel...well-crafted.

With deep breaths and lots of elbow grease, we massively refactored fmSpark and adopted a quasi Model-View-Controller approach to scripting.

I won't get into the gory details here except to note that the core idea is to delegate different responsibilities to different scripts--those that are (a) responsible for supporting user interface and interaction, (b) making changes to the state of the data (the model) and (c) those scripts that mediate between the previous two.

I should note that Todd Geist (Geist Interactive) has done excellent series of articles on his blog about this topic, check them out here. Our actual implementation may differ but I think our strategies for dealing with spaghetti code turned out to be very similar.

To be sure, this MVC-inspired approach will continue to evolve but we are already seeing the dividends of the extra effort. I'll share one final bit of development statistics. After a thorough scrubbing, we've been able to deprecate over 80 scripts--here's a picture of all the stuff that is going away!