This post and others like it relate back to an introductory post that explains the point. This is an edited variant of something I wrote in 2007. This is the section for software I have written or otherwise been involved in the creation of, be it in the form of testing, customer relations, determining requirements, debugging, management, or whatever. It overlaps with things I have mentioned elsewhere, but deserves its own category even had I mentioned it all elsewhere. There are probably things I have forgotten, or that are too small or incomplete to be worth mentioning even if I remember them. Do web sites count as something akin to software development projects? I’m not counting them, but that would be another angle, given the various sites I’ve created or helped create, modified or maintained (these days they arguably do, but I’d still say that’s if there’s substantive programminc elements). In no particular order, the list as best I can remember…
Proof of concept internet keyword search engine
Web Response Tracker
XTreme Data XChange
XTreme Time Minder
Winlaw Scanning & Archiver Utility
Winlaw Closing Wizard
Technology Management System (TMS)
Custom groundskeeping billing in Access VBA
Prometheus PDF Supplement
Blood Pressure Logger
Too many samples and snippets of code to count, including publicly available ones like this textbox tip and sample, but mostly for customers of VB support.
There are things I was peripheral to, where perhaps I dealt with a client, or was aware of the nature of the code being written or improved, but was not in a position to see or be involved in it myself. For instance, a stock analysis program co-written on-site with our client at their offices in Rhode Island. Three of my colleagues worked on it, with one of them flying to California to deploy the application and configure Oracle for the client’s customer. For another instance, a CRM/sales management tool for an insurance company in Connecticut.
The item I listed as “Proof of concept internet keyword search engine” borders on that, but I was actively involved in the planning and testing, and evaluating the proposal. That was in the early days; 1997 and just into 1998. Someone had the bright idea, of which we were skeptical, of selling keywords. In your TV ad you’d tell people to type “cars” in their browser. No http. No www. Just a word. Remember, this was a long time ago. That would provoke a search at the host site, looking up the URL that matched the word. Then the user would be redirected to the URL; perhaps a page on the car company’s site advertising a special in detail. The guy behind this wanted it to be available in time for the Super Bowl, and wanted the thing to be able to handle the sheer volume of traffic that might imply.
We never got paid a cent, but neither did we provide anyone with code. However, it was serious and, until they ran out of money, apparently well enough backed that we were supplied with a massive HP server to use for testing. It was up there with some of the best machines one might deploy as servers back then. A couple of my colleagues did their magic, writing some code. We networked with the server, hit it with massive traffic tests, and couldn’t even get it to break a sweat. That was cool. Then the whole thing fell apart. They didn’t want to pay us realistic money for it anyway, and the guy behind it apparently ran out of funding, so nothing happened. Except for subsequent, presumably unrelated developments online that made the idea look better than we’d thought at the time.
Backtracking a bit, I covered Escalation Assistant in the tech support tools post. I wrote it to add uniformity to and help ensure completeness of the details supplied in the text of escalations to second level Microsoft Visual Basic support. It was kind of cool to have written something, even if it wasn’t particularly large or fancy, that was used by most of the department.
Ditto on having talked about the Web Response Tracker and Web Coach programs before. I believe the former was the first programming project I ever oversaw without writing it myself. It was a great experience. The latter is notable in that my friend and colleague Bob saw me working on it with gleeful intensity and observed how much fun I was having, and that I was kind of a natural at it. That brought home to me that, indeed, he was right. Sometimes I regret having not pursued programming as a vocation.
The WebWizard I had forgotten about until I poked around to see if I’d missed anything. In answering web responses – support requests people left via the web site rather than by calling – there were certain elements that were uniform or recyclable. One of the thing I did was establish certain standard protocols and bits of text used in responses. For instance, letting someone know that the answer above should resolve their problem, and we would close the case after so many days if we didn’t hear back. Something like that saved us having to harass the customer into actively saying they were all set and saved us accumulating open cases that were open only because the customer never replied. In two partially written variants, I set out to automate parts of that. The trouble was, I distracted myself by creating a cool splash screen on which an animated spider dropped down and up a strand of web. It was strictly voluntary and experimental, so no biggie, and I had fun.
The Training Evaluation project is another I mentioned earlier, and another project I oversaw. It was written by my friend and colleague of the time, Nicole.
Programs I called Time Trakz and Time Minder were two different timekeeping programs I created and used for billing purposes. The first had start, pause, resume and stop buttons and would, using them, stopwatch and increment your time for you. We weren’t really using that feature and it was easier simply to type in how much time, and the big client requested a particular way of categorizing work (which six years later they declared too ambiguous). So I wrote a new version used until the business closed, initially against SQL Server 7.0, then with Access. I never “finished” it in terms of things I’d have liked to add, but it served the purpose. There were times I’d have liked something web-based, or an e-mail parser, but hey.
Data XChange is a big story. The story of the entire business, in a way. A cautionary story about what could and did go wrong.
When I left Tranti Systems and ended up in Word support, I had developed a misguided urge to be self-employed. I knew I needed and wanted to learn more, but even as I started that support job, I had a vague notion I’d stay there several months or a year, absorb more knowledge, and then leave for some vaguely defined “computer consulting” self-employment. That job showed me how much I didn’t know, and was comfortable enough, especially during the first several months, it diverted my original plan to flee and go out on my own. I never fully forgot it, but it receded.
While in VB support, some of us were dismayed when comparing our abilities to that of the developers we were helping, who made far more money than we did. That led some of my colleagues to discuss starting a side business. They brought me in on it, after choosing a name but before meeting officially for the first time. It started as much as a social club as a business, but the initial idea was to write software we could sell in some quantity. That was music to my ears. While we had others who were downright prodigal at programming, I made plans for product marketing, production and fulfillment.
Another thing we knew from support was that there was demand for a utility to convert between database formats, including things like going backward from newer to older Access. That would be our first product, which we called Data XChange. Since we named it in 1996, use of “xchange” and “data xchange” in some form or another has exploded from nothing to absurd, if not as absurd as the proliferation of use of the word “xtreme” in some form.
That hummed along nicely. Some of us gave feedback on the interface and helped with testing. Others pounded out the code. Within several months we had a 1.0 product that quite literally could have been released with caveats, then patched or updated in a 2.0 version. However, one partner insisted that it had to ship with absolutely complete and bug free functionality. No warning people that it couldn’t handle Paradox indexes reliably, or whatnot, for the almost nobody to whom that would matter. Another partner insisted it had to be completely rewritten from scratch, object-oriented, enabling us to sell an SDK version as well. At that point the creative energy deflated, everyone else steered away from it, and the partner with the big plans to rewrite it never even started. We did manage to get a copy of the code modified to disable all but conversion between Access data versions and made that available as a free download.
We missed the opportunity to bring in enough money to keep people excited and to pay us to continue improving it. The business structure, which fell into partnership by default, precluded the ability to supervise and direct the work in any traditional manner. There were also too many of us, with too many differing ideas of what we ought to do for a buck. Thus we steered into the consulting/custom software direction. Which was always something we were open to, but some of us had a greater desire to go with “packaged” software as much as possible.
Flash forward a bit, and we had a company looking for a limited functionality SDK version of Data XChange, meaning a DLL they could call to do the conversion task. They only needed it to go one way, between Access versions. The partner who’d wanted to do the SDK approach sat down and wrote what was needed within a couple hours. Some quick testing and it was in the hands of the customer. I charged them not for custom, but for what we’d retail it, and I was excited to be able to market even a limited SDK Data XChange product. When I tried to get the code from my partner, he had lost it to an fdisk he’d just happened to do right after writing it and getting it out to the customer. After his pride at how little time it took, he refused to spend the couple hours to recreate it. Meanwhile, it was cool to know that a copy of our DLL was installed in several hundred locations in the U.S., Canada and Mexico, but it was irritating to lose all that prospective revenue.
This post isn’t supposed to be about lessons in business or software development, but it can’t help but be just that, or else lack much detail.
I discussed Winlaw under legal software. It was originated by another company, as a custom package for a law firm that ranged between 40 and 52 people in size. They apparently hoped to make it a standard offering to other firms. We imrpoved it, as it had serious problems, and upgraded it to 32-bit. I did a lot of UI tweaks, plus functionality improvements and bug fixes over the years I maintained it.
One of the features we were contracted to add was a closing wizard, to more comprehensively gather information about a case as it was being closed. I designed the interface and worked with the client on requirements. With my help and supervision, one of my partners wrote the meat of the code and we ported it from a standalone program for ease of development into Winlaw proper.
Another element of the Winlaw project was the addition of a program for archiving documents. I wrote that one, and made it so it could also be used less emphatically, to make a mere copy of all the documents from a case. That turned out to be the most used feature, as it was used in conjunction with scanning externally sourced paper documents at the time each case closed, to have a snapshot on CD of the documents as they appeared on the server then.
The Winlaw project ended up having elements in common with Data XChange, and our business elements in common with the originators of Winlaw. In the latter case, the story was that the partner whose baby Winlaw was left the company, nobody else there cared about it, and that was why the client had to hire us to fix it. In the former case, my partner who was the primary on the project got a certain amount done and then decided it just had to be written entirely from scratch. A pattern emerges. The benefit of that would be we could have a more widely marketable version, while also fully satisfying the original requirements and some. That was where Prometheus came in, and as far as it went, it was amazing. In both versions; the first one wasn’t good enough and was tossed when it was mostly complete, to be rewritten from scratch. A pattern continues. Then the partner whose project Prometheus was left.
I deployed a version of it in beta for a small firm. That was the hard part. Once in service, it worked great. Until they needed to handle PDF files, and not merely Word and other MS Office file types. While I tried to figure out how to create a plug-in that would work for PDF files, I created a side program they could use to associate selected PDF files with a case, list the ones for a case, and open them. Too much of a kludge, but it was better than nothing for a time.
For me, the whole code writing thing wasn’t so bad, except it didn’t have anything like a current payoff, and quite possibly it had no payoff, ever. In the case of Winlaw, the agreed upon price was absurd, and not in our favor, even had we ultimately collected all of it.
Kidpaint is a silly yet cool little program I wrote while still in VB support. It’s pretty much how it sounds, and could also double as a demo of some of the graphics methods available natively in VB, which were one of the things I taught in VB training. There’s a drawing area, with a background color that can be change. You can switch between each of the different “pens.” You can select a width. A separate form below the main form has colors to pick from, resembling an old watercolor paint set. A separate form beside the main form lets you click on an icon-sized picture and then click to “stamp” it onto the drawing. Left-click is once only, while right-click leaves it available to stamp over and over. Right draw is randomly multicolor, while left draw is the selected color. You can show or hide the colors or stamps. It’s cute, but not sophisticated. It pleased me years later to see my own children use it.
Technology Management System, or TMS, was a project we did for a long defunct company named Marine Optical. The sad thing is that they showed every sign of being on the verge of going under, and being likely not to pay us for the whole thing, but the money – and somewhat fascinating project – beckoned and blinded us to the signs. We did most of the work, but were technically hired as consultants/contractors to work with one of their IT employees on creating it.
It was a program for people at the company to put in work requests of the IT department. The manager of a department would approve a request by one of their employees. The manager of IT would approve and assign things as the ultimate arbiter. The tough part was the way in which they wanted a combination of assigned priority, time in the queue, and absolute priority overrides by the IT manager to be computed and interact. I ended up being the only one with a clear grasp of what they were asking, but I wasn’t the one writing the code, so I did a lot of explaining. I basically managed the project. My partner spent his last week before taking a full time job over at the client’s building, helping the co-writer there prepare it for deployment. Between his leaving and our knowing they wanted to save money, we left some finishing touches and creation of reports to them.
A few weeks later, their employee got stuck, had modified the code in a suboptimal way, and it came back on us. In about five weeks, we almost doubled the cost of the project, fixing it, debugging and polishing it up, and doing after all the things they’d have saved money doing internally. In a way, I had a lot of fun that month, working with another partner on troubleshooting and modifying the code. What happened, though, is the partner who’d done most of it in the first place would stop by after work, take over from us, wipe out what we’d done and write whole swaths of code from scratch, concluding that what he’d done initially wasn’t good enough.
We managed to get it just finished and deployable by the end of the year. Their employee still was unable to deploy it. His boss, the IT manager, left. Once she was gone, after the beginning of the year they were in full throes toward bankruptcy and there was no chance we’d ever get paid, and within a few months he was laid off too. It was bad. The program was excellent, though. Some of the requirements were a bit odd, but a similar program would probably have worked fine for many companies as an IT management tool. Indeed, they wanted custom then because nothing off the shelf quite fit them.
I was essentially manager, customer contact and support person for a custom billing solution for a small groundskeeping business. It was in Access VBA. The biggest problem was probably the lack of feedback from the customer as to precisely what he needed. He simply liked to talk and talk socially, but left us almost on our own when it came to business. He also didn’t have the approval of his wife to have the project done, when she would be the user. In actually deployment, the biggest problems were lack of computer skill and comfort, and ease with which entering bad data would crash it. The good thing was anyone who could open an Access table and eyeball the data could fix it. In theory. It was interesting and kind of cool, but should probably have been done in VB, even if it meant greater cost.
Quote Factory was my name for a project I started and didn’t get much past the UI on. It was for generating printing price quotes. This time I saw and heeded the warning signs we probably wouldn’t get paid, and that it would have too much depth. There was also the classic mistake of showing the customer a GUI and having him see it as practically a done program.
Icon Extractor is a program I wrote to show and be able to copy to the clipboard any icons contained in a file such as a DLL or EXE. I also wrote a simpler one long before that to display and zoom in on ICO files, and to copy them. Cool, if essentially little more than samples of how to do a particular thing.
The password generator is something I created to give me random looking yet relatively easy to remember passwords for people, based on certain inputs, one of them internal to the user database.
The blood pressure logger would have been completely pointless, except that it gave me something to try writing with Visual Basic 4.0 beta. I would enter blood pressure readings I got, checking sometimes several times a day, and it would append them to a Word document. That way I was able to give the doctor a printout of readings, dates, times, and circumstances.
Finally, the least significant of the above are little more than sample code. There was tons of that. In support, we had to be careful we weren’t writing people’s programs for them, but sometimes we got carried away. Since that was product support, there was more to it than code, including Visual Basic and Visual Studio installation problems, and distribution problems with programs written in VB. That last one could effectively mean being product support for someone else’s program, at least to the point of getting it to install. But I digress.
This is the end of “list” posts of software, hardware, and the above projects. I’ll move on to other posts about my experience that are closer to what you might traditionally see in a resume, or an expansion of same.