In addition to my "day" jobs, I have been involved in a number of freelance projects over the years that have contributed greatly to my professional growth.

One such project is my blog, Undocumented Features. It began as a general blog on technical and business issues, but over the first few months morphed into a project management blog. I am currently planning to overhaul this blog and rename it something more appropriate, and start an analysis blog in the Undocumented Features URL. You can find more details regarding this on the "Blogs" link of this site.

I also have been involved in a number of open source projects over time, including operating systems, helpdesk systems, crm systems, IT operational management systems, and various desktop applications and games. The most significant project from a time and complexity factor was an early online multiplayer roleplaying game (which, although successful and operational for many years, is unfortunately now defunct- such is the way of the gaming world). This project was significant in both the scope, the complexity, the processes, the training, and the challenges.

The scope and complexity covered everything from the simple ability to pick up and interact with objects that had size, bulk, weight, and various properties within the game to complex combat systems and the ability for characters to craft their own objects, buildings, shops, and areas of the game world. The number of functions and functional requirements of the game measured into the thousands.

The real challenge, however, was the staff and the process. I had the good fortune to work with someone who was an experienced release engineer and helped to implement a complete SDLC process including source code control and change management. I managed project scope, requirements gathering and definition, and quality assurance on the project. I also managed development training and staff allocation. Our staff consisted of volunteers that we recruited online, and myself and my friend were the only trained developers. Every other staff member we trained in the programming language, the software development process, and in object-oriented programming- on the job. Most of them were basic computer users when they began who barely knew the way through Windows Explorer. We also never met most of these people. I personally met four staff members ever, and I believe that my friend who helped manage the project (who I myself have not met personally yet) met about five others. Our staff overall consisted of twenty to thirty programmers at any given time.

Of all my "off-work" projects, I have always been most proud of this one. Managing a large virtual team, not only through unfamiliar processes but teaching an entire programming language, is not a trivial task. The game took several years to complete, of course, but we were able to go to beta and have players in-game within six months, and with a remarkably low bug rate for our project. The reported bug to function ratio was less than .1%. Most bugs were usually tied to unique situations within the game. The difference in Beta to production-stable was in fact mostly addition of new abilities, as opposed to corrections to existing functions. We had an informal schedule, but we also stayed remarkably close to this- most people hit their deadlines within 20%, many times coming in early rather than late. Most professional software projects using trained staff cannot report these sorts of results.