These products were developed for social service institutions, recreational clubs, and other non-profit organizations. To this end, no compensation was accepted, save for an expensive dinner or two.
Although obviously minor works, each is worthy of remark and rememberance in its own way. Unfortunately, these projects are part of ancient history, and thus were mostly created using obsolete languages and technologies. Obtaining proper screenshots would require untold hours reconstructing original development environments, so a little creativity was required.
This project may seem trivial — and this lengthy "making of" featurette far out of proportion to its importance — but it shows my life-long love of programming in crystal-clear resolution. I was just a free-coding, mentor-less kid who somehow unwittingly used quasi-professional development methodology — juxtaposed, as it was, against the kind of machine-level hacks that were so often required to make things work back in ye olden times. I miss terribly the thrill of seat-of-your-pants keyboard-mangling, and would love to find a project that provides that experience again while still supporting my family. If you know of any such opportunity, please share it with me!
In 1988, our high-school chemistry teacher got the idea to enlist a computer match-making service for a physical science club Valentine's Day fundraiser. I was titillated by the concept, but being who I was, insisted on implementing it myself: It just sounded, like, totally bitchin'. (Did I mention this was the '80s?)
The idea — which was met with considerable excitement — was to distribute to students a questionnaire intended to both identify and quantify individual characteristics in four broad categories: Morals and ethics, life objectives, general interests, and romantic expectations. Completed questionnaires would form the candidate data pool. After analysis, each "client" could purchase a list of "most compatible" counterparts, including category-specific and overall "confidence factors" for each match.
A R C H I T E C T U R E A N D I M P L E M E N T A T I O N
Within weeks, I'd banged-out two applications running on the venerable Commodore 64:
The first was an all-BASIC program that enabled club members to 1) create, revise, and print questionnaires, 2) assign weighted values to questions for use by the analysis algorithms, and 3) enter data from completed questionnaires. ;-) Questions were structured in four formats: Multiple-choice, check-all-that-apply, rank-by-importance, and open-ended lists. Component-level database technology simply didn't exist on the Commodore platform, so I created a system that used indexed, relative-access files to store input data.
The second program processed and analyzed questionnaire data, eventually producing match lists. Safeguards were instituted to flag and log suspect data. Comparing answers to multiple-choice questions and check-all-that-apply data was simple enough. Rank-by-importance analysis used averaged, differential computations. Open-ended lists called for a human to make common-sense modifications when entering data (such as correcting obvious spelling errors), then for a set of partial-string-matching functions, including metrics-calculation so the program could objectively judge (more guess-at-non-wildly than judge, actually) the reliability of each matching set. In hindsight, these functions amounted to a most primitive and early version of natural language processing, I suppose.
The string-matching functions were originally written in BASIC, but they proved so dirt-slow when looped-over against anything more than a tiny data pool that I resorted to coding them in 6502 assembly. This would've been fine except that I'd recently spilled sweet tea on a pile of floppies that included both the original and backup copies of my assembler. (Yeah, I know: Storing backups in such geospatial proximity to the originals defeats much of the purpose of backups. Leave me alone.) In 1988 rural Kentucky, you didn't just bop down to your local K-Mart for programming tools, and our runway was short, so panic ensued.
I eventually crafted the assembly by hand — literally, as in "pencil on paper" — then converted the mnemonics to machine-language op-codes. To avoid errors and save time, I used a tiny utility to convert hex addresses and operands to decimal before aggregating them into DATA statements. Using loops, I POKEd the data into memory blocks that were safe from BASIC code and variable-storage, then called the functions from BASIC using SYS statements. Admittedly, this was all fairly-common methodology during this computing era, but it generally included an assembler! ;-) After a few assemble-by-hand/test/debug-by-hand cycles, I had some efficient string-matching functions and a working data-analysis program.
T E S T I N G A N D R E V I S I O N
At my suggestion, the club enthusiastically formed what today might be called a quality assurance team: They recruited what were perceived to be happy, stable couples to complete the test questionnaires, filled out questionnaires of their own, created dummy questionnaires for fictional clients, entered the data, and ran the analysis program in hopes that the generated matches would prominently feature the real-world couples. Based on the resulting matches and on follow-up conversations (i.e. post-mortems) with the lovebirds, they'd then modify the questions and/or their weighted-values and repeat the process.
In essence, they implemented their own tweak/test/debug cycles to keep improving the service, at least as well as they could in light of their limited and subjective test data. We were just a bunch of high-school kids using pseudo-science to describe and predict the most mysterious of human-interactions. In 1988. On a 64 KB, 8-bit machine running at 1.023 MHz. I think we did pretty well.
L A U N C H A N D C A N C E L L A T I O N
By the end of January, we were pushing out questionnaires and pulling in cash. Students offered almost nothing but encouraging comments, and the limited but impassioned dissension only stoked interest in our activities. Anticipation was even higher than we'd dreamed. The feedback spurred us to add a premium feature (more money!) that would provide match results against a specific student who didn't already appear in a client's best-match list. The fervor was simply exhilarating, and it lasted about two days.
That's when the club president and I were summoned by the principal. The school newspaper had just published a brief story covering our efforts, which we considered a terrific piece of flawlessly-timed publicity. (It included some errant details, but that happens to me every. stinking. time I'm interviewed for any reason.) Unfortunately, the moment a copy hit the principal's desk, he apparently spewed coffee through both nostrils and hit the roof. We were ordered to cancel our fundraiser and issue immediate refunds, as his head swam in visions of livid, litigious parents beating down his office doors the instant one of our matched-couples went down in tearful, hurtful flames. He was quite adamant that allowing us to proceed would be akin to school-sponsorship, and he was offering to us whatever the opposite of sponsorship is.
P O S T - M O R T E M
In hindsight, we perhaps could've continued our efforts off-grounds and without further school resources: I can recall neither why we didn't nor wheter the suggestion was even made. As it was, we spent much of the remainder of the semester explaining, ad nauseam, why our service never emerged as promised. My first commercial project ended up being my first vaporware.
As silly as it is, I'm still a little bitter that our ambitions were forcefully-aborted. Can you imagine the roller-coaster reactions and colorful fallout when our system was run against 800+ hormone-ravaged, angst-filled teenagers who spend five to seven days a week together? Fireworks pretty! Still, the entire experience was extraordinary fun, and I'd relish the opportunity to help create another product with a similar gee-whiz factor. Somehow, I doubt working at eHarmony could bring the same delight. Worse, if I'd more foresight, my friends and I might BE eHarmony. Opportunity squandered.:-(
While this is certainly one of the most unexciting projects imaginable, I've never hacked anything else in quite the same way, so I thought it worthy of inclusion.
In the late '90s, my wife volunteered at a local pregnancy center in our college town. Of course, doing so auto-tagged me as the resident IT guy, tasked with handling all the usual hardware issues and solving every indecipherable access violation and blue screen of death. As this was during the reign of Windows 95, there was a shortage of neither.
D E V E L O P M E N T
The center was using a client-tracking program, aptly named ClientTrack. Everyone was perfectly happy with this program, but there was still a great deal of data in an older piece of software that they never found time to re-key into ClientTrack. Since the center served many repeat clients, it made sense to integrate this data.
My first thought was to use a hex editor to identify the older program's storage scheme, as I'd previously done in similar situations. However, it soon became obvious that untangling the knots in the overly-convoluted and purposely-cryptic layout would stretch my sanity. (Did I mention I wasn't getting paid for this?) No, this task called for a different approach.
The old program was DOS-based and used fixed field sizes, so theoretically, I could screen-scrape records from display memory and append or merge it to ClientTrack's database. (Thankfully, ClientTrack's creators weren't compelled to obfuscate their data scheme to oblivion as their counterparts apparently were.) Since my data-scraper would live between the two client-tracking apps, "Intercession" seemed as apt a name as any. (Why I even bothered to name a throwaway program is a question for my psychoanalyst, but the fact is, I name everything I create.)
Fortunately, when in the old program's "browse" mode, the user could scroll through records using CTRL + CRSR_DN, and through record subsections using CTRL + CRSR_RT. So, I employed the old-as-silicon technique of stuffing the keyboard buffer followed by a time-delay before each screen-scrape, and Shazam!
P O S T - M O R T E M
There was some trial-and-error regarding the timer duration, and a few false starts from incorrect character counts, but once I worked through those issues, Intercession was able to unify all data. Insanity postponed.
Once the Paducah Chess Club grew beyond a handful of members, the need for computerization quickly became obvious. The club wanted software to manage members, seed competitions, record results, compute rankings, and automate various other tasks.
D E V E L O P M E N T
Phase one was a straight-forward database application that tracked player contact information, United States Chess Federation membership details, official ratings, club dues, and the like.
Phase two was far more novel, intended to assume many of the duties normally required of the tournament director and other officials. Using the player information from Phase 1, the software could set up either a multi-game match, or a round-robin, Swiss, and/or direct-elimination tournament in a matter of minutes. Initial player color could be assigned randomly or manually. Game results would be entered into the system, which enabled pairings to be calculated on a round-by-round basis, although they, too, could be manually overridden when necessary.
Usually, only game results were entered, but complete game scores (including the complete move sequence) could be recorded for later replay. The replay code used Commodore character graphics for the board and a partially-redefined custom character set for the units. Game results were compiled into players' "career records" and used for various performance-analysis functions added over the life of the program. All pools, brackets, standings, and other data could be printed for public posting, either with or without the character graphics comprising tables and pairings. (Letter-quality printers weren't able to produce graphics, so they were included only if printing to a dot-matrix printer or plotter.)
P O S T - M O R T E M
From Blade Technologies principal Jason Purcell:
The system ran on an SX-64, a twenty-three pound "portable" version of the Commodore 64. ;-) I considered porting it to the PC and issuing it as shareware, as it would've been a fairly straight-forward translation except for the character graphics. However, the use of such technology in chess was largely-unheard of at the time (late '80s / early '90s), and the realm was so tradition-bound that I could envision no reception other than resistance and apathy. Time proved me wrong: Like everything else, the chess world runs on a chip, now.
Developed for Murray State University's Fencing Club, Riposte! is very similar to Chess Exchange in its dual-purpose design of club management and tournament administration. However, it was a creation of considerably greater scope.
D E V E L O P M E N T
Once again, the first step was to push out a module to maintain the club roster, except this time, it was also built to keep tabs on other clubs and schools, equipment suppliers, division officials, and coaches. Club profiles included photographs, contact information, United States Fencing Association (USFA) membership details, official ratings, and account balances. Each contact type included native, specialized fields as well as user-defined fields. Photos could be imported via TWAIN-compatible cameras and scanners, and cropped and resized using a simple, built-in editor.
Fencing competition administration is particularly error-prone, so this functionality was first bullet-proofed, then gold-plated. Leveraging information from the aforementioned fencer profiles, the software correctly divided competitors into even-strength pools and later seeded finalists into direct-elimination (DE) brackets. It auto-resolved a lengthy list of conflicts and handled many tedious details, separating fencers from the same club, indicating each fencer's side of the strip, tracking each scoring action, reminding the director when fencers should salute and switch sides, keeping time, issuing various warnings and signals, implementing the sanctioned tie-breaking algorithm, recording each penalty, displaying prescribed punishments, and calculating both pre- and post-tournament ratings.
The entire array of documents required by the USFA at event-completion could be sent to printer or converted to HTML. (Adobe considered PDF a military-level secret at the time.) Pool sheets, DE brackets, and DE score-sheets were printed for directors and public posting during competition, as well.
P O S T - M O R T E M
From Blade Technologies principal Jason Purcell:
Probably the most shiny thing about the system was a second executable I created to drive an external display with a series of screens showing the immediate and cumulative results, the upcoming bouts, and a series of configurable announcements. Now, I know that's no big deal today — I see similar setups at my daughter's gymnastics competitions (though they convey nothing more than immediate individual results). However, I finished developing this program in the late fall of 2000, so it was at least slightly ahead of most of the pack.
Though the market was (and still is) minuscule and a number of competitors existed even at that time, this software was so complete that I should've pitched it to the USFA as soon as it was tested in a tournament. Instead, I decided to first develop a data-connected companion-product that directors could hold in their hands while conducting live bouts, and — in a stroke of geeky optimism — chose the Palm OS as my platform. (Stop laughing — I was hardly alone!) I actually did start on this app around Christmas, but of course, the bottom fell out of Palm (and its stock) the next year. If anyone's interested in how I planned to develop a dependable mobile network application in an age without dependable mobile networks, check out the Palm Query Applications (PQA) quasi-API. If PQA didn't work, I was going to roll-my-own, which is my natural tendency, anyway.
I'd still love to port the entire thing to .NET and direct someone to create an HTML5, cross-platform companion app, but I can't imagine how I'd justify the time-and-materials in light of the minimal potential return: I'm not a childless twenty-something anymore. As Blurryface is repeatedly and directly admonished, "Wake up, you need to make money!"