fmSpark would look better with...
Now that fmSpark is functionally complete, it's missing something. Specifically, it's missing sample data. We can't simply dump in a list made-up names and addresses and create random data; fmSpark needs data that looks good, by which I mean templates that demonstrate how good your email (and letters and labels) can look using fmSpark.
Looking good says to me "graphic designer" which is one of the services around fmSpark we're considering. Currently we have a couple of basic styles in and we're creating sample mailings for them. It was in the process of creating sample data that we of course found a new bug. It was quickly stomped but I feel I may need to resign myself to the idea that there may be a bug lurking somewhere just out of sight until fmSpark is in the wild. I'm counting on you not noticing it while you marvel at how simple it was to send out that stunning mailing.
fmSpark, Behind the Curtain
First, a big thank you to our BETA testers and our partners at SeedCode! We've been getting excellent feedback and bug reports, and fmSpark will be a much better product for it.
So, where do these bug reports go and how do we handle them?
Here's a quick look behind scenes. From the get go, one of the things we wanted to make sure we took seriously at Proof was the business of tracking defects and issues. At Proof, our issue tracking software is at the center of our development universe. There are lots of different tools out there, but we use Jira by Atlassian Software.
The attitude here is if it is not logged in Jira, it ain't an issue.
And you know what? While it took some getting used to at first, I don't know how we got by without it. One cool thing about using an issue tracker is that you get lots of self-generated documentation for just being disciplined. Want to know what changed between build 204 and build 407? Well, guess what, no more guessing.
The recipe for success with issue-tracking software is this: (1) the tool needs to be institutionlized and become part of everyday practice, (2) no-one gets a free-pass--if you are part of the project you need to participate and use the tool. I have found that it simply works best when no one is too important to be exempt from logging issues or following the rules; and the rules are simple;) (3) if you are working on an issue, make sure you comment the ticket; if you log an issue, put some effort into it!
Here's a screenshot of what fmSpark looks like from the perspective of our issue tracker.
fmSpark coming Real Soon Now™
As we get closer to pushing fmSpark out the door there are a few issues remaining to be finished off. Having been in this business for more years than I care to admit, I am nevertheless surprised when beta testers find bugs that were missed during development. No matter how much time you spend with the product, refining and tweaking and bug stomping, there will nonetheless be a few that slip out the door. I'm happy to say that all known bugs have now been squashed and fmSpark will be released shortly.
The last issue remaining is with the set of "API" scripts. fmSpark is designed as a module to be integrated into your solution with minimal fuss. To do so we created a set of scripts we call "APIs" that are the scripting "interface" to fmSpark. Rather than have you creating scripts in your solution to create mailings, you instead call the "API" with a list of record IDs and with the type of mailing to create and fmSpark handles the rest. The API scripts work, but our motto is "as simple as possible, but no simpler" hence this one last task.
fmSpark 1.0 in BETA!
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!
