Marshall J. Ellis

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…

Escalation Assistant
Proof of concept internet keyword search engine
Web Response Tracker
Web Coach
WebWizard
Training Evaluation
XTreme Data XChange
XTreme TimeTrakz
XTreme Time Minder
Winlaw
Winlaw Scanning & Archiver Utility
Winlaw Closing Wizard
Kidpaint
Technology Management System (TMS)
Custom groundskeeping billing in Access VBA
Prometheus
Prometheus PDF Supplement
Quote Factory
Icon Extractor
Password Generator
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.

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, in this case, the part on programming tools, languages and such. As usual, I may be forgetting some that would fit here, especially if I dabbled more recently. Also, lest one get excited, just because I have laid hands on a language, perhaps written a “hello world” program with it, maybe compared its language and syntax on paper, that does not mean proficiency, or even familiarity. It’s merely indicative of a bit of added depth to my overall background. The only things I’d claim proficiency in are VB through 6.0, Wordbasic from Word 6.0, and perhaps VBA as applied to later versions of Word and Access. In no particular order, the list as best I can remember…

Visual Basic 3.0 through 6.0
QuickBasic 4.5
Professional Devlopment System 7.1
Visual Basic for DOS
VBA
WordBasic
Visual Basic.NET
VBScript
JavaScript
PHP
J
Borland C++
Borland Delphi
MS Visual C++
C#
BASIC
Pascal
Cobol
HTML
Visual Interdev
Visual J++
Visual FoxPro
Rexx
MS-DOS batches
Perl

I think I’ve looked at other things like Python or Ruby, but I can’t remember exactly which, so I left them out of the list. I definitely played with, and helped a friend with, Perl. J is something I discovered a couple years back, downloaded and played with a bit. I find it fascinating to look at new languages.

The first six items on the list I supported for Microsoft to some degree or another. Officially in Word support we did not support macros, but that was my specialty and we tended to make exceptions to some degree. That carried over into automation of Word from VB programs, which later meant becoming familiar with VBA when Wordbasic was replaced. Right around the time I migrated from Word to VB support, the first Word macro virus hit. Because I’d shown you could do some mischievous things with macros, colleagues jokingly suggested I might have been the source. Flattering, in a twisted sort of way.

The interesting thing about supporting a programming product is that you get a huge range of exposure that you might not get coding a project, but you don’t get the intense depth in one area that coding a project that uses certain features might impart. You also learn how to find things out in support, which is extremely useful. I always emphasized when providing references that the candidate in question might not know a specific thing – there’s too much for anyone to know it all pat – but troubleshooting and research ability on top of the broader knowledge are a huge benefit. Sometimes it was depressing talking to software developers and realizing just how bad many were, yet they were making real money. Sometimes it was weird having limited knowledge about a customer’s question, compared to them, yet having enough knowledge, access to information, and alternate perspective to cut right to it and look like a miracle worker. Despite having started the call in a panic because you didn’t know much about X.

There were obsolete products we supported for a time. The training was all about VB3 and then VB4. If someone called about the DOS versions of Basic or VB, it got interesting. Even when it wasn’t someone doing something goofy like running QuickBasic from floppies on an ancient PC without a hard drive. (Perhaps the equivalent in Word support was when someone couldn’t make Word 6.0 run on a 286, where I congratulated them for getting Windows to run and could do nothing for them.) It helped that I had dabbled with BASIC off and on since I learned my first bits of it circa 1977.

Before I even got the job in Word support, I had bought and installed Borland’s C++ product, dabbled with it slightly, and eventually read a book and tried the code it taught. The Absolute Beginner’s Guide to C Programming or something like that; great book. I dabbled just as slightly with some of Microsoft’s versions. More recently I tried to run and compile a component one of my old partners wrote in VC++ to be used from Prometheus, our case/document management product.

Pascal and COBOL were classes in college. That and I dabbled with Delphi, which used a form of Pascal. What was weird was when I read the book Code Complete, it gave examples and comparisons in various languages, and Pascal always looked surprisingly familiar to me. It’s kind of like French from 7th, 8th and 9th grade. I can see or even hear French and it doesn’t sound alien to me the way another language other than English or German might. Years later, when I took German, I’d find myself needing the German word and inexplicably remembering the French word for something, and usually forgetting the German in the process. I’d have told you I’d forgotten it long ago, but there it was, bubbling up.

It’s hard not to have learned some HTML, or at least gotten comfortable looking at it, after having web sites for seventeen years. Still, I am not a wizard and like tools that make it easier.

I poked Rexx with a stick when I played with OS/2 Warp, having seen much discussion of it ahead of time among Team OS/2 denizens. I don’t remember anything, but I know I touched it and was naturally curious after hearing so much.

Whereas I did a lot with DOS batch files, which do count as a form of programming/macro language/tool. I still do. My most recent VB program was a quick utility to read a couple of fields from an Access database and write out a text file with traditional file I/O (rather than referencing FSO – File System Objects – and going beyond an EXE that would run fine after a straight copy to the target machine). The fields were original and current paths of archived documents. Restoring them called for a mass of copy commands using the two paths. Nothing fancy.

It’s funny; I could probably have gone ahead and done programming for a living. I’m better than I generally give myself credit for, and certainly more of a natural, but I tended to be surrounded by people who were prodigal by comparison. In a business started originally to write software, that was why I was the business guy, along with some testing, user interface work and such. I’m good at orchestrating the activities of other people, understanding requirements, and grasping a whole project. I’m good at debugging existing code. I’m good at making attractive and usable interfaces, or improving existing ones. Sometimes I think about it and it seems cool. Sometimes I think about it and it sounds onerous to have to maintain that level of concentration all day, each day. Which is not actually how it works, because that just isn’t possible, which is one reason why production of code isn’t as voluminously fast as some less technical types might anticipate.

When dotnet came out, none of us were doing Visual Basic support anymore. That meant we wouldn’t receive the customary training and were on our own. While I and others checked it out on our own to some degree, which was frustrating when it took forever to figure out how to do the equivalent of Form2.Show and other simple things that were the beauty of VB, it wasn’t the same. So I organized a couple of day long sessions at my old office. A bunch of us gathered around several computers and banged away at it, getting pointers from anyone who knew more about or was faster to figure out a given thing. It was excellent. We also had some partial training material from within Microsoft to look at. Other than that and playing with it (and C#) a bit before and after, I’ve not used dotnet. Code I’ve maintained or worked on has continued to be in VB6. There was no reason to change that.

Oh, forgot VBA. I’ve used it directly and through automation in MS Office products. I’ve also looked at the VBA kit that came with MSDN, and in at least one non-Microsoft application. I seem to recall that having been Lotus WordPro, and the app-specific commands having seemed rather obscure even by Word VBA standards. One of my partners created an Access-based application using VBA, a custom billing program, for a groundskeeping business. I helped with it some, and was primary contact for the customer. Actually, I ended up doing most of the support, debugging and testing. It seemed best to use Access directly, because of the convenience of generating reports as invoices. It was so shaky (mainly prone to collapse under the slightest bad data) that a real program in VB might have been better and not much more time-consuming. We ended up charging what the customer was willing to pay, which was about a third of what it was “worth” by the hour. The partner had nothing else doing at the time. At any rate, that was a big education in Access VBA.

There you have it. This will sort of overlap one of the remaining sections, in which I list and discuss software I was involved in creating (or attempting to create) on at some level.

Next up, server software.

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, in this case, call center and tech support related software. In no particular order, the list as best I can remember…

Aspect call center monitoring
Microsoft PSS Workbench
Clarify Compass
Wadle
MSDN
Technet
Escalation Assistant
Web Response Tracker
Web Coach
Training Evaluation
V-BeGone
Regclean

The first four items were a part of doing Microsoft support and, later, being a technical supervisor. MSDN and Technet were tools we also used at times, and sort of indirectly support the use of.

Escalation Assistant was a program I wrote, used in VB support, to gather the appropriate information about a case – ensuring that people did indeed gather as well as include all of it – before escalating to second level support. It would format the details and put it all on the clipboard to paste into Compass. The people handling escalations were very appreciative.

I helped pioneer “web response” online support by the VB team. Initially I volunteered to do web responses between calls, during a time when we were adequately staffed. One Monday, the second level contact at Microsoft assigned me all the web responses the weekend guy had summarily escalated because he’d not had time to do them, effectively choosing me to do web responses, rather than phone support, full time. Since I loved writing responses, that was fantastic.

We ended up with a team of people doing them, me in the lead. I supervised the creation of a program for tracking the web responses we did.

When I became a supervisor (“technical development lead,” TDL for short) and phased out of doing web responses, one of my jobs was “coaching.” That is, listening to people and giving them feedback on their support calls. How do you do that with written responses? How do you randomize it? I wrote a little program to randomly select a case to read, for a selected support tech, during a specified time period.

Finally, as TDL I ended up in charge of training, which turned out to be one of those things I do best (which really is a specific application of a more general trait). Not the training, though I’m good at that too, once I get past the terror of speaking to a group, but planning, orchestrating, and changing the details as circumstances dictate. I did a few parts myself, but for most of it I lined up others with the appropriate strengths, and lined up future trainers to learn from current trainers of some topics.

It had been traditional for the trainees to fill out paper evaluation forms. I supervised and tested the creation of a program to gather the same data, which put it into a more useful format.

It occured to me to wonder where one might mention things like making Regedit dance and sing, or using sysinfo, dxdiag, or whatever. That reminded me of Regclean, which I seem to recall was originated by someone on the VB (or perhaps developer support more generally) team at Microsoft as a way to cleanup obsolete registrations of OCX files and such. That in turn reminded me of a utility called V-BeGone, written by one of my colleagues. We used it to have people comprehensively get the OCX and OCA files specific to Visual Basic (as it existed at the time) out of the way without affecting third party controls.

Some of this overlaps the category of software I wrote, managed, or was otherwise involved in.

Next up, languages and programming tools.