“You should ALWAYS make backups of your data. You never know when you computer will take a permanent siesta.”

I commit all of my source code to a subversion repository on my local machine, and I regularly take snapshots of that development machine, which I keep on an external hard drive. In case of a failure I’d suffer two or three days of lost data. A week, tops.

Lately, my computer’s primary hard drive has been making funny noises, like a tiny helicopter flying into a narrow fjord, deep within my laptop. So I’ve been extra diligent about backups.

On Friday, it finally died.

During the boot-up process, it went into a ten-minute chkdisk loop before ultimately succumbing to a horrible BSOD.

After that… nada.

No problem. I bought a new drive and prepared to transfer everything over. After installing the operating system onto the new drive, I connected the backup drive (in its own external USB enclosure) and listened, horrified, as it made a few pathetic clicks and whirring noises.

Dead.

Huh. That’s weird.

This drive had been chugging along without complaint just a few hours beforehand, and suddenly, it’s a complete brick. The operating system doesn’t recognize it at all. It may as well be a can of sardines.

I fiddled with the connections, finally taking apart the enclosure, swapping the cables. Still nothing. The drive is definitely kaput.

Keep in mind, this is not just my source code. This is my entire life. Software projects, art projects, letters, stories, email archives, proposals, invoices, tax documents, from the last seven or eight years.

I felt like my house had burned down.

Panicked now, I connected the old laptop disk, to see what I could salvage.

As it turns out, there was still a lot there.

Even though the operating system wouldn’t boot, and some entire directory hierarchies had vanished in a puff of corruption, I was able to salvage nearly all of my personal documents (in fact, as far as I can tell, all of my photos and documents survived).

But the source code is riddled with holes. Entire projects are just completely gone. (And about a third of my MP3 collection. The horror!)

The application analytics project–which I’ve been working on since June–is particularly decimated. From a total of probably 30,000 lines of code, I’d say about 25% has vanished. The entire server project is nowhere to be found. (The entire embeddable library project and about 90% of the reporting client GUI survived.)

I was able to recover an old, crusty snapshot of the server code (from September) by manually slogging around in the raw subversion data files.

Also completely gone: a set of ActionScript support libraries, with data structures and algorithms for the charts & graphs in the reporting client. Luckily, at the end of December, I started the process of moving my source code–starting with this particular library–to a repository on a remotely hosted (and independently managed) server.

Thank God for small miracles, right? At least if I could recover that code, I’d save myself the trouble of reimplementing about three or four thousand lines of code.

So I tried doing a check-out, but guess what!

There’s nothing there.

Browsing remotely with Tortoise SVN, the server happily responds that the repository is empty. And the web SVN interface says that I don’t have access to the repository. Which is odd… since it also lists a record of my most recent check-ins.

Wouldn’t it be funny if that repository had somehow evaporated?

Is someone playing a joke on me? Am I being punk’d?

I’m going to send my (two!!) failed hard drives to a data recovery company tomorrow. Maybe they can do better than me at recovering some of this lost files. Yikes.

Anybody want to make a small wager that the data recovery facility will burn to the ground the moment my FedEx package arrives?

Within the next couple of months, I’m going to release the full product suite. The server is written in Java and the reporting GUI will be deployed as an Adobe AIR application, but those aren’t what I want to talk about today. Today I just want to provide a sneak-peek into the embeddable library that developers will link into their own applications to enable statistical reporting.

The embeddable library is written in the D programming language, which compiles to native code and exposes C linkage. (DLLs on Windows and SOs on Linux; the OSX compiler is a little out of date and has some bugs, but rumor has it that it’s going to get a major overhaul in the near future.) Initially, I’m only going to support C/C++ deployment on Windows and Linux. But shortly thereafter, I’m going to write wrappers for Java and .NET. And hopefully the OSX compiler will be up to snuff by this summer.

I’m shooting for maximum compatibility with the most in-demand development platforms, so I’m going to let users tell me which wrappers they’re most interested in seeing. (Chances are very good that I’ll also write a Flash/Flex/ActionScript implementation, to support analytics on RIA applications. My recent development experience in Flex has been exceptionally pleasant. Stay tuned!)

Another one of my goals is to make it absolutely dirt-simple for developers to use the library. In the most basic cases, it should take fewer than five lines of code.

Here’s a simple case:

#include <AnalyticsLib.h>

void main() {

  char* sessionId = AnalyticsLib.createSession(
     "https://stats.mydomain.com:8080/",
     "MyDeveloperId", "MyApplicationId", "MyApp Version 1.0.6"
  );

  /* ...application logic goes here... */

  AnalyticsLIb.closeSession(sessionId);
}

Aaaaaand that’s it!

Easy like Sunday morning!

The analytics library starts a background thread that handles all the nitty-gritty details. It caches all of its data locally (on disk), periodically communicating with the server (over HTTPS, if you like) and flushing its local cache. If the application (or computer) crashes suddenly, the data is all recoverable. The next time the user starts your application the analytics library will flush the data from the previous session, along with a flag indicating that session terminated abnormally.

If the user disconnects form the internet, or if the server goes offline for whatever reason (upgrades, restarts, etc), no problem. The library will cache its data on disk and re-submit later, when the network is connected and server is online. If it can’t submit the data during the current session, it’ll submit the next time the user runs your application.

When the library finally does connect with the server, they exchange a series of one-time-only, one-way-hashed authentication tokens, to prevent casual mischief-makers from sending the server bogus data.

Every time a new session is created, the library inspects the local operating environment, collecting information about the current device:

• The operating system name and version.
• The CPU name, speed, and number of cores.
• The total amount of system RAM.
• The number of local hard drives, and their total capacity and available space.
• The number of screens, and their dimensions.
• The presence (and versions) of the JVM and CLR.
• The network bandwidth (bytes per second, downstream).

If you need other information about the local environment (like maybe the installed version of some particular DLL) you can collect that info too. It’s part of the API, which we’ll get into later, but it’s not built into the default environment inspection process.

NOTE: As a customer of this product, you’ll have to agree not to collect any personally-identifiable user information. It will be one of the terms of the license. You’ll also have to disclose to your users that you’re collecting anonymous usage data. The last decade has proven that it’s possible to collect anonymous statistical data on the web without breaching user privacy, and I stay within those bounds.

Along with the environment data, the library will also automatically report some historical device-usage statistics:

• The start and end times of the session.
• The currently-deployed version of the software.
• The total cumulative number of sessions originating from this device.
• The elapsed time since the previous session.
• The elapsed time since installation.

Beyond the automatically-collected device and session information, the analytics library also provides a simple API for reporting developer-configurable data, in four different categories: environment variables, benchmarks, events, and logs.

Once you’ve created a session, if you need to collect any environment variables not already included in the default installation, you can call a simple function in the analytics library to submit your own:

AnalyticsLib.envNumeric("Workstation Uptime (Minutes)", 673.25);
AnalyticsLib.envText("Python Version", "2.5.2");

Environment variables are reported only once per session. Re-submitting a new value for a previously submitted environment variable will overwrite the old value with the new.

If you’re concerned about the performance characteristics of your code on your users’ computers, you can run benchmarks locally and submit the results of those benchmarks for analysis later. Wouldn’t it be great to know the mean, median, and standard deviations of the execution time for some expensive function in your code? Do most of your users have blazing fast computers, or are most of them running pokey old-timer machines?

double units = 10000; // The cross-referenced document contains 10,000 words.
AnalyticsLib.submitBenchmark("Document Cross-Reference", millis, units);

The benchmark API allows you to specify the number of work-units performed by your code as well as its execution time. Later, you can use this information to produce charts and graphs examining how your code’s execution time scales with its dataset. Do your algorithms have logarithmic or quadratic performance characteristics? If you submit benchmark data from within your application, you’ll be able to produce histograms reports for your entire user base.

And, of course, you’ll be able to compare the benchmarks of various different user groups. Is your application’s performance more sensitive to CPU speed or to the amount of system RAM?

The analytics library also provides an API for submitting arbitrary events. An event is an instantaneous moment in time, with an associated name, and optional textual and numeric values. Here are a few examples:

// User disconnected from the network.
AnalyticsLib.event("NetworkDisconnect");

// User was idle for 1 hour.
AnalyticsLib.eventNumeric("BackFromIdleState", 60.0);

// User invoked the SpellCheck feature, from the Tools|Text hierarchy.
// You can report on any level of this hierarchy.
AnalyticsLib.eventText("FeatureInvoke", "Tools|Text|SpellCheck");

// User spent 6 minutes reading the 'Beginner Tutorial' page in the Help system.
AnalyticsLib.eventTextNumeric("HelpSystem", "Beginner Tutorial", 6.0);

With these events, you’ll be able to write complex reports to analyze the usage patterns of your users. How fully do your trial users explore the user interface? Do your “premium version” users actually use the premium features that they paid for? Although your users have long-running sessions (maybe they run your software all day long at work), how much time do they spend actively in the application, verses letting it sit idle in the background?

Finally, the analytics library provides a mechanism for submitting log data.

try {
   doSomething();
} catch (const MyException& e) {
   char* failureType = e.getFailureType();
   char* message = e.getMessage();
   AnalyticsLib.log("3D Rendering Subsystem", failureType, message);
}

In your ongoing effort to improve product quality, you can inspect those remote error logs to find the hard-to-reproduce faults that never seem to occur in your own development environment. You can even run statistical reports about the modules where the errors originated, the types of errors that occur, the types of devices where they occur most often, and the events immediately preceding the crash.

So those are the features! I hope you’re as excited as I am to see this stuff finally see the light of day in a few months.

Like I’ve said before, the embeddable library is about 90% complete (which is why I can describe it with such detail at this point). Currently, the lion’s share of my time is going into the GUI implementation. And boy is it going to be sexy. I couln’t be happier with the Adobe AIR platform. The Flex API is extremely well-designed, and the event-driven model is excellent. Also: the graphics are stunning. Pixel-perfection in a highly-functional GUI is finally possible, and I’m happy to say that the user interface is a near-verbatim recreation of my original mockup.

ActionScript, as a programming language, leaves a *little* to be desired, but it’s pretty decent, and the development environment is very productive.

Anyhow, I’m still working my ass off to get a 1.0 version released by the end of Q1, but I wanted to provide you guys with some of the implementation details that I’m hammering out, so that you can start salivating for the release.

Anyone interested in beta testing?

A sun-bleached steer skull gleams under the hot desert sky.

And tumbleweed creeps across the road, bumping against the old hitching post.

It’s been a ghost town around here lately, since I posted my last message in June, and the lost signs of life have not gone unnoticed a few of you out there.

Three or four times a month, I get an email from someone curious about my Desktop Analytics project, who maybe saw the GUI mockup, and wondered whether I was still around and still actively working on an implementation.

As it turns out, I’m still here. And I’m still working hard.

In fact, the ongoing emails from interested bystanders have really kept me motivated and have reaffirmed my confidence in the strength of the concept. As my way of saying thank you to the people who have sent me their questions, I’ll take a little time tonight to give you a long-overdue status report. Then, sometime within the next few days, I’ll post a sneak peak into the architecture I’m developing and some of the cool features that I hope to unleash on my users early next year.

I’m thinking…mid to late Q1…

First, a quick refresher, for those of you who might not have been around when I originally floated this idea.

I’m building an application analytics platform, analogous in many ways to Google Analytics or Omniture. But those solutions focus on analyzing web traffic to answer questions like “which search engine keywords provide me with the most traffic?” and “which of my content resources have the highest click-conversion ratio?” Those types of metrics were invented my the advertising industry for messuring consumer responses to ad campaigns. Long before Google emerged from the labs at Stanford, ad executives asked Nielsen analysts for their conversion numbers.

The web analytics software on the market today still reflects that mentality: the internet is a medium for delivering content. Some of that content attracts a lot of eyeballs. Some of those eyeballs tell their mouse-fingers to clicky on an ad. And some of ad-clickers buy hilarious cat calendars from Amazon.com.

Web analytics is all about maximizing throughput of the content/eyeball/mouse-finger/cat-calendar pipeline.

Developers of applications, rather than publishers of web content or cat calendars, get short shrift in the whole equation. Sure, we can get detailed statistics about which types of web surfers are more likely to download our products. But when the last byte finishes downloading, our visibility into that user’s behavior evaporates.

I want an analytics package that tells me how users actually interact with my software.

How many people are using that new spellcheck feature I spent so much time developing? How often do my users fire up the application? Every day? Once a week? Do they use the software all day long, or just for a few minutes in the morning? How many menu clicks does it take to find certain features? Are people getting lost in my user interface? Do they invoke the HELP system? Do the “Premium Edition” users actually use any of the premium features, or do their behavior patterns look just like the “Free Edition” users? How many people are still using a legacy version, and which features should I improve, to motivate an upgrade decision among those users?

Answering questions like that will help me develop better software.

And I like to think that “better software” is almost as important as “good keywords” in driving new revenue.

Anyhoo…I hope I’ve gotten you a little sweaty and breathless…

Now: status report. Tomorrow: architecture details.

The software comes in three pieces: an embeddable library, a server, and a reporting client.

The embeddable library is a tiny piece of code that developers will link into their own “host” applications. The code is written in a snazzy little programming language called D, which compiles to native machine code, providing C linkage on Windows and on x86 Linux and OSX. No matter what language or platform you’ve used to write your application, as long as it provides some mechanism for linking with C libraries, you’ll be able to embed the analytics library in your code.

As of today, the Windows version of the embeddable library is about 95% complete (the OSX and Linux versions are about 75% done).

The server is implemented in Java, so you can run it pretty much anywhere (I personally recommend a “Mr Coffee” deployment environment). The server is about 85% finished, and can handle about 100 requests per second on my dinky little 2-year old laptop. It doesn’t use Tomcat or JBoss, and it doesn’t depend on a gazillion application frameworks. It’s a standalone HTTP server, talking to a MySQL backend, and you can get it up and running within minutes (hint: no XML configuration).

Finally, there’s the reporting client, with all the sexy charts and graphs. I’m only about 10% done here, after making a bold decision to switch my development environment. I started out working in C# with WPF/XAML, but I recently switched to Flash/Flex/AIR (for reasons that I’ll describe in more detail later) and now I’m playing catch-up.

That’s all for now :o)

I’ll be back soon with more details. But right now, I just wanted to check in with you guys, let you know that the project is still rolling forward, and that I’m anticipating a Q109 release.

I’ve made the following platform choices:

Initially, the embeddable client library will strictly provide a C interface for Windows. In future versions, I’ll also provide wrappers in popular high-level languages, starting with C# and Java. At some point, the library will also be available for Linux and Mac OS X.

The server will be developed as a standalone Java server (i.e., without requiring Tomcat or JBoss or anything like that) with a MySQL backend. Future versions will enable more database choices (probably starting with SQL Server), though I won’t develop a non-Java version.

In a subsequent version, I’ll also release a “reflector” module in PHP/MySQL. The reflector will be a dumb server component that listens for events from the embedded client library and stuffs them into a database. Periodically, it will connect to the main server and send a batch of data. The purpose of the reflector module will be for developers who don’t want their users to see an outgoing HTTP request to an unfamiliar domain, but who don’t want to actually host the main server themselves. At some point, the reflector will probably also serve as a load-balancer and/or a failover mechanism.

The reporting client, with all the fancy charts, will be developed in C# using the .Net 3.5 framework, for maximum WPF goodness.

Thanks again for your help in choosing platforms!

Do you use Java or .Net to develop your desktop software? Or are you maybe using C++ with MFC or WxWidgets? Anyone selling desktop software built with Ruby or Python?

Do you have a server? Is it Windows or Linux? Do you have your own server, or do you use a VPS account? Or just a shared web server, with PHP/MySQL? Do you have permission to install your own software into your server environment? Are you already running a Java app server? Tomcat, or something else?

Whatever platforms people seem interested in are the ones I’ll focus on in my development, so express you preferences here!

Without any additional commentary on my part, what do you think of that design? I’ll answer questions in the comments section.

Something, perhaps, to express your knowledge of contemporary video-game pop culture, while simultaneously making an ironic commentary about being a complete social misfit. Not just a run-of-the-mill computer nerd. But maybe a former a member of an actual high school band. Brass section.

Maybe something like this…

Oh yeah. That’s the stuff.

To buy that shirt, you’ll need to surf on over to the Torso Pants website, where you’ll find a truckload of other pithy outerwear. No matter what ironic outings you’ve planned with your friends this summer, you’ll find a breezy 100% cotton tee with the perfect one-liner somewhere on TorsoPants.com.

While you’re there, open up the HTML source in your favorite text editor and scroll waaaaay down to the bottom. There, you’ll notice a SCRIPT tag, linking to code from a google.com domain. And if you’ve been involved in web development – in even the slightest capacity – over the last two or three years, you’ll immediately recognize that ubiquitous little snippet of JavaScript as belonging to the embeddable Google Analytics library.

Anyone with a GA account can paste those two lines of JavaScript into her website’s design template and immediately start collecting a broad array of metrics about the site’s users, their browser environments, and how they interact with the website. Most importantly, the marketing department can see where their incoming links are coming from, which types of users tend to buy (or not buy) which types of products, and which advertising campaigns are most efficient at converting which eyeballs into dollar bills.

The Torso Pants people can actually quantify the hilariousity of their t-shirts by comparing the popularity of the product pages, even among people who don’t buy! For my money, Tuba Hero is at least 35% more hilarious than Homeschool Valedictorian.

Right about now, given the vast scope of my readership, I assume the guys from the TorsoPants marketing department are looking at a blip on those charts, wondering what the hell is going on. The abnormal rate of traffic from this page will surely show up on their dashboard, and they’ll probably click on over here to investigate. (Hi guys!! I’m sure you don’t mind my borrowing one of your images, cuz of all the free advertising I’m sending over? Right?)

I picked the Torso Pants website for my little story to illustrate the fact that pretty much every company (small or large) doing business on the internet is currently using business intelligence, usually in the form of Google Analytics, to optimize every aspect of their online presence. Torso Pants is just one example out of millions of other small businesses with the same snippet of JavaScript on their pages. The few companies not using GA have — almost without fail — implemented the more sophisticated (and enterprisey (and therefore more complex (and significantly more expensive))) solutions from Omniture or WebTrends.

But the idea is the same.

From the placement of links to the wording of ad copy, every element of the interaction design can be studied and optimized using a web analytics platform, performing A/B testing about the effectiveness of different ads, different landing pages, different offers, different prices, and so on and so forth.

In fact, the existence of these analytic tools on the web provides one of the most substantial positive arguments for developing a new software application as a webapp, rather than on a desktop platform. Even if the web development process is more cumbersome. Even if it means additional IT staff to deploy and manage the online app. And even if the browser environment degrades the user experience.

Releasing your product on the web means you can easily incorporate a sophisticated statistics package, by just pasting two lines of code into a single template file.

It’s hard to argue with that.

But what if there was an analytics package for desktop applications? What if the integration process was as simple as linking to a library and pasting two lines of code into your own project? How would that change the equation? And why is the competitive landscape so crowded in the web analytics marketplace be so barren in the desktop analytics space?

I’ve spent the last few months thinking about just such a platform, wondering what kinds of things you could learn about your users. How could you use that intelligence to design and build better software? Here are a few of the ideas I came up with:

• First of all, how many people are actually using your application? You might know how many people downloaded it, but do you know how often they launch it? Do they use it every day? Maybe only once a week, or once a month? Is it used mostly Monday through Friday, during the day? Or primarily on evenings and weekends, implying the difference between corporate purchasing and leisure and hobby users? After using the application for a week or two, do most people uninstall it, or do they start using it even more?
• Do your users have shiny new, high-powered machines running Vista with 4 gigs of RAM, or are they clunking along in Windows 98 on a Pentium II? Do they have Java? What version? Do they use multiple high-resolution monitors, or do they run mostly on laptops? You probably have more downloads from Windows users than from Mac users, but which population of downloaders is more likely to become a group of loyal users?
• How long does it take your trial users to finally buy a license? If you offer a 30-day trial, do people use the software during the full trial period, or do they launch your software only once? Maybe those people who uninstall at the end of the trial would buy your software if the price was lower. Users who abandon the software long before the end of the trial probably used the software for one task and satisfied their need. Maybe you should offer a shorter trial. Or maybe you should offer a money-back guarantee and get rid of the trial altogether.
• How many people are using pirated serial numbers? Do some of your licensed users install on both a desktop and laptop computer? Those users provide an excellent way of determining which features are more well-suited to each platform, since you can observe the same person’s behavior in two different contexts.
• Maybe you offer a “Pro” or “Enterprise” edition, with a few extra features for a few extra dollars. Do people actually use those premium features? How often? Which features are the most valuable? If people don’t actually use those features, you might need to redesign the distribution of features among your product editions, to take best advantage of your pricing segmentation opportunities.
• Do people get lost in the user interface? How often do they browse through the main menu before clicking on a menu item (indicating they’re having a hard time finding features)? When invoking commands, do people prefer keyboard shortcuts, context menus, toolbar buttons, or the main menu? Maybe you just implemented the vaunted “Office Ribbon” interface. Do people switch back and forth between ribbon panels without choosing an option (again, because they can’t find the right button)?
• When you release a new version of your software, how long does it take your users to upgrade? Do some of your high-volume users resist upgrades, even across major versions? Maybe the features in the new version didn’t capture the interest of those long-time users. That’s a big problem, because in most businesses, your existing customer base is the richest source of new sales.
• Do your users actually read the Help docs? Is it because they understand your software really well? Or is it because they don’t know how to find the Help system? Do they read the docs immediately after installation (maybe because of a confusing interface) or only after a few weeks or months of usage (maybe because the interface is easy to use at first, but the advanced features are hard to understand)? When people do read the docs, what topics tend to be most popular?
• What if you could run a snippet of profiling code on every user computer, to get a baseline performance benchmark for all of your users? What if you could get stack-traces for exceptions thrown on remote machines? What if you could see which devices, platforms, and configurations contribute to the most errors? Should you spend a lot of time fixing those errors, or should you just tell people that Windows 95 is not supported?

Those are the types of questions I hope to answer with my software. And so that’s the focus of my project for the month of June.

Of course, the product I’m describing here is more than a 30-day project. But I don’t intend to stop at the end of the month. In this article, I’m defining the long term vision, and over the course of this month (and, realistically, probably part of the next month) to restrict the scope to something a little more bite-sized for version 1.0.

I hope that sounds as exciting to you guys as it does to me. I’m completely psyched for this project.

At the moment, I’m about 60% finished designing the database schema. I’ve written a few bits and pieces of code (Java and .NET) for the embeddable libraries. And I’ve spent a lot of time (altogether, about a week) working on the user interface design sketches.

While the primary goal of the project is to provide a truckload of business intelligence about desktop software deployments, I also want to provide the most gorgeous, detailed charts ever seen in a BI platform. I’ve been reading a lot of Edward Tufte lately, and I’ve been absolutely slaving over the GUI. So far, I’m really happy with how it’s going.

But more about that later.

I’ll be back within the next day or two with more details. And pictures!

In the mean time, let me know if this is the type of thing you’d be interested in. Based on the bullet points above, are those the kinds of stats that would help you in the development and marketing of your software? What other kinds of stats would you like to collect? (Incidentally, my personal checklist is much longer than what I included above; I trimmed it substantially for publication.)

If this sounds like it’d provide value to your company, let me know some details about your development platform and process. (Either comment below or send an email to benji@benjismith.net.)

What platform do you develop on? Java? .Net? Mac? Would you rather run the server component yourself, or would you prefer a hosted solution (knowing that the cost of the standalone version would probably be about the same as a year of the hosted subscription version)? If you’d rather host it yourself, what does your server environment look like? Windows or Linux? Do you run your own servers? Are you on a VPS? Do you (god forbid) use a shared-hosting provider? Depending on the size of your user population, it might be necessary to get dedicated hardware for a server like this. Would you be okay with that?

I’ll concentrate on producing embeddable libraries and server components that are compatible with the deployment requirements of the biggest segment of prospective customers. So if you’re even remotely interested, let me know!

Holy crap! I’m currently in the process of designing and building a product in 30 days. A whole bunch of other software developers are doing the same thing, at the same time, during June 2008. Everybody’s blogging about the process, and all of our RSS feeds are being aggregated into a single incredible feed. You can follow along here.

During that time, I did a lot of blogging (sometimes as late as 3am, to write a blog entry while on vacation, after everyone else had fallen asleep). The whole endeavor really got me into a mindset of wide-open possibilities, to the point where it was hard to stop thinking of new ideas and actually focus on just one.

(I’m going to make a bold statement: The people who complain about a lack of software ideas have never really spent a significant chunk of time going through a methodical brainstorming process.)

Now, after two years, I’m finally making good on the implied promise of that brainstorming month.

At the end of June, I’m going to release a new product.

Later this afternoon, I’m going to write my first line of code.

Before I get into all the details of the project, I’ll tell you a little bit of the back-story of how I got from there to here…

Anyhow, back when I finished that month of brainstorming, I made a decision about the best idea in the bunch and started working on an analytics application for the stock market. I was a little nervous about competition from the big online brokerages, since E-Trade and AmeriTrade had already started offering advanced charting and analytics tools with their basic accounts. But I kept working on that project for about six months before finally crumbling under a few major obstacles.

Most importantly: I couldn’t find a data vendor who could provide the type of data I wanted to bundle with my application.

Since I didn’t think I could cobble together a satisfactory data feed, and since I had planned for the feed to be the work-horse of my revenue strategy, I scrapped the project.

At that point, I got an offer for a job in Boston, with the promise of a leadership role in the research department of a well-funded media startup. I moved across the country to accept the position, putting my entrepreneurial ambitions on the back-burner again for another year or so.

Last November, I left that job (on good terms, of course :) to start my own company, with the intention of using consulting projects to bootstrap my product development ambitions. The self-employment thing has worked out well. I really really enjoy the flexibility, the creative freedom, and the sense of strategic ownership (also: I have the coolest boss ever).

My biggest consulting project was vast and complex and researchy (I was working on a prototype of an agent-based collaborative decision-making simulation), so I didn’t actually have much time to spend on my own product.

Anyhow, I wrapped up the big project a few weeks ago (the client decided to pass on the full implementation), and all of my other projects had already wound down over the previous month or two.

As I comb through my professional network looking for new projects, I nevertheless have a lot of time on my hands to finally do some solid product development. But within the next month or so, I expect to find a new client, and then I’ll be up to my eyeballs in consulting work again.

That means I only have about 30 days to get as much work done as is humanly possible. At the end of June, or potentially early in July, I need to be ready with a beta-stage product.

And, as the fates would have it, there’s a whole gaggle of other solo software entrepreneurs doing the same damn thing!!

They have a website and an RSS feed and they’ve described the response from the one-man-software-company community as “incredible interest“.

Looks like June is officially “Get Down to Brass Tacks and Finally Build Your Damn Product Month”.

Maybe in November we can all write novels together…

So, everyone’s going to be blogging about their experiences, talking about their design and implementation and marketing processes. Looks like it’ll be a real hootenanny, and I thought it’d be fun to throw my hat into the ring as well.

I have a novel product idea (not one of the ideas from the 30-day brainstorming project, though). I have a few graphic design sketches. And I have the utmost confidence in the marketability of the product. It’s ambitiously big for one person (especially given the constrained time-frame), but if anyone can do it, I can.

Over the next 30 days, I’ll tell you all about it.

Hooray for me!!

The new company is called Wry Research, and at least at first, I’m mostly just doing AI research consulting for a couple of clients. I’m trying to also fit in some original product development, when I have spare time. But I don’t have a whole hell of a lot of spare time, so I’m mostly just consulting right now.

But life is very good, and I’m enjoying the freedom and flexibility of being a solo software developer.

In the near future, I’ll talk about some of the work I’m doing as a consultant. I’ll also talk a little bit about a really cool research project that I’m doing, in conjunction with the Columbia Medical School Neurovascular Research Lab. Depending on the success of the research, it could lead me to developing a very cool product/service for the medical research community.

I’ll keep ya posted :)

Unfortunately for those of us in the United States, the puzzle is not available here, and there are very few online retailers willing to ship the puzzle to the USA.

But I did track down the puzzle at Hamley’s and placed my order. Their online shopping cart is a little bit crappy (it got confused verifying my non-European billing address), so I had to call them on the phone ( (+44) 800 2802 444) and a very friendly girl with an Irish accent took my order.

I placed the order at noon last Wednesday, and the package was delivered (in Boston, MA) by about 2:00 pm on Friday.

Holy crap.

At first, I thought they must have used an American order-fulfillment location, but the package had international shipping stickers and a return address in the UK, so it seems to be an actual international delivery. Fulfilled in just two days. I’m very very impressed. I had no idea that it was even possible to ship something overseas so quickly.

The puzzle cost £35, plus another £25 for shipping. With today’s lousy exchange rates and the weak dollar, that’s a total of $120. Unfortunately, when I win the $2 million prize, that means I’ll really only be netting $119,999,880.

Bummer.

Anyhow, if any of you American algorithm enthusiasts have been sulking because you can’t get Eternity II here, sulk no more!!