My time at Walker Interactive Systems, a now defunct Mainframe financials company, served both as my transition out of the Army and into the civilian world, and as my introduction to life as a professional programmer.  It marked a rapid change in many of my attitudes about life, software, and business.

When I started at Walker, the company had recently gone through a round of layoffs, and was just recovering enough to start hiring again.  Many of the people on staff around me were veterans of the company, somewhat jaded, and ready to move on.  When I started in January of 1997, there were two other developers on my Group:  Laura and Tony.  By the time August rolled around, they were both gone.

I worked in a group developing internal software.  The end users were primarily the consultants of the company who customized the software for the end users.  Overall, the company sold a suite of financial software:  General Ledger, Accounts Receivable, and the like.  The software ran on IBM System 390 mainframes.  Customers were behemoths like AAFES, and one of the Airlines (I think United).  The primary software was designed to run on a 3270 terminal:  a fixed size, fixed font terminal run on a screen by screen basis.  It was an old technology.  Keystrokes were scanned and processed by the terminal software and stayed on the local system until an explicit “Enter” command would send the whole buffer back to the mainframe.

My team was responsible for turning these screens into an API that Visual Basic programmers could use, a process known as screen scraping.  An off line process would read the database of screens, including position and length information, and store it in a database on client side.  Code inside the applications would act like a terminal, buffer up the changed information, and send it back and forth to the mainframe.  The code to execute this was split into two pieces, one for the UI and one for direct communication to the mainframe.  When Laura left, I inherited the front end.  When Tony left, I got the rest.

Microsoft technology was then at the DCOM stage.  What had started as Object Linking and Embedding had evolved into a development philosophy that pervaded the various flavors of the Operating systems at that time:  Windows 95, NT4.  I became a student of the component object model, learned about monikers and marshalling, reflective cross language interfaces, and remote procedure calls.  Wrox Press provided most of the information I needed, and Stacey’s bookstore graciously provided me access to spend a portion of my salary to purchase the books I needed.

The first thing I did was a rewrite of the UI code.  This was less a matter of Hubris and more a matter of it being easier to learn by writing than understanding the existing code base.  The existing code was in C, and I was immersed in C++.  The existing code was a series of dynamic link libraries for the non-preemptive-multitasking version of windows that had been forward ported to Win32, but that had much of the vestiges of the older systems.  The old code was more error handling than anything else.  My version had the benefit of focusing on a single platform.  Since I had the freedom to develop the code from scratch without worrying about backwards compatibility, it made it much easier to make the new code re-entrant, something that the old code had to work to prevent.

One big lesson learned from this effort was to respect the amount of embedded knowledge that there is in a pre-existing code base.  After the first release of my code, I spent a lot of time fielding bug reports from the UI developers about features I had missed.  I learned the value of having a quick-to-run debugging code driver that allowed me to easily reproduce their problems.  The integrated debugger was invaluable in stepping through, viewing what was actually happening, and allowing me to quickly make and distribute fixes.  I got the notion of step through your code drilled into my bones.

When adapting the Gateway code, I had to deal once again with the rapidly changing API from Microsoft.  The older method of remote procedure call was deprecated.  DCOM was the new hotness.   After much trial and error with their Interface Defintion Language (IDL) and SAFEARRAYS I finally got a simple network service to run.  Since my version was expected to be remote, we had reduced licensing from each client machine to a single NT server as well…or at least the potential to do that.  Not sure if the company ever followed up on it.

Of course, all of this distracted me from what I was “supposed” to be working on:  the replacement for the screen scraping which was an asynchronous messaging layer.  This was my first exposure to the recurring theme that I will state here as a rule:  Never name a software project Phoenix.  Really, do you want to imply that your project will go down in flames, dying time and time again?  This project phoenix was no different.  The concept was good:  pull out a section of the cobol code that could be executed as a standalone transaction.  Turn this into an asynchronos message and let the developers send the message to the mainframe.  The reality was that so much of Walkers code would needed to be restructures that even after we got the messaging layer working, the concept was unusable.

One of the end goals of the messaging layer was to work with Data Bound Controls.  There are things like spread sheeets and fields that can be bound to a column from a database query.  Since that meant playing nicely with the Microsfot database technoligies, I dove in and made the messaging layer an OLEDB Provider.  If this doesn’t scare, just be glad and move on with you life.  If this does scare you, then you know way too much about microsoft technologies and I feel somewhat sorry for you.  Basically, I had to learn about the technology that microsoft was then pimping as a replacement for ODBC, a tehcnology which never really should have caught on, and a technology that should be quietly taken out to the back 40 and shot.

One bug while developing the OLEDB provider took me two weeks to track down and fix.  THe mistake was mina and mine alone.  I was apassing in a NULL to a field that required an allocated structure.  THe problem was that, while I owned the calling and implementing code, in the middle it had to go through a microsoft technology called Active DAta Objects (ADO).  This particular API was closed source.  I could see only the disaassembly of the executing code, which didn’t provide the context I needed to deduce my mistake.  This adventure really sold me on the concept of Free (as in Speech) Software and Open Source coding.  I had just started experimenting with Linux, and this really drove home why the development model was so successful.

The very tail end of my time at Walker was spent learning about Java.  IBM was pushing Visual Age, and the company was planning a bitg transition. Walker really suffered from the .com boom:  people fled to cooler, more interesting jobs throughout 1998 and 99.  I left in the summer of 99 to go to Fort Point Partners, a botique services company that was pretty focused on ATG/Dynamo and eCommerce.  Soon after I left, I happened across a group of former co-workers there.  We chatted and they let me know that the company was then very Java and Websphere focused.  Not long after that, Walker was acquired and then passed on to the corporate afterlife.