Software Development

I purchased my first computer in late 1981, a Commodore VIC-20. The VIC was a remarkable machine for the price with on-board sound and graphics as well as a proprietary BASIC language loaded into ROM. The computer came with 5 KB of RAM of which, only 3,583 Bytes were allocated for programming. Though expansion modules were available, they were expensive and did not seem worth the price as the computer wars were heating up.


Commodore's BASIC was, well, basic. Unlike todays Visual Basic, this language required each line of code to be numbered. Branching was performed by calling the line number. Armed with their optional cassette storage, I eagerly dove into learning how to code. Two things quickly became clear:

1) Sequentially numbering lines of code prevented adding lines in between without a very time-consuming (and confusing) overhaul of the complete code module.

2) Spacing each line of code by perhaps 10 (10, 20, 30...) allowed inserting additional code, but the line numbers gobbled valuable RAM - there were only 3,583 Bytes, remember?


Despite these drawbacks, I created several useful programs. I remeber one computed standings of remote-control cars we raced outdoors. That code was complex and had to be modified many times to fit into the allocated RAM. If that computer taught me one thing, it was how to code efficiently - something I use to this day.


I kept-up with technology, purchasing a new computer when processing and the Windows API made it worthwhile. Along with advances in processing and operating systems, software became more advanced.

The Pentiums and Windows 95, coincided with our growing business's requirement for data retention, retrieval, and analysis. Still, business software was DOS-like and clunky. With no Automation, everything had to be performed within a single application. I certainly got sticker shock in 1995 when I shopped around. The business software was sold as 'modules' with a base price of $70,000 (remember, this is 1995!). Any additions would be custom and cost $200 per hour to implement. After picking myself up off the floor, I decided to roll my own software.


In late 1996, equipped with only a vision and some basic BASIC experience, I purchase MS Access 95 and began to learn OOP and all its Methods, Properties, and Actions. Since Access graphical SQL was limited, I learned how to write complicated SQL to write and retrieve data. Working from 5PM til 9PM each weeknight and 6AM to 9PM every weekend, it took 6 months to scale the steep learning curve required to put together a basic product. One year later and an upgrade to Access 97, I had a fully functional business application. Running on a Peer-To-Peer network, the data was kept on a backend "server". The frontend supplied all departments with detailed data, presented in an intuitive manner. First with DDE, then with OLE, parts orders were automatically faxed to vendors for replenishment. Photos of the thousands of parts were proudly displayed within the Parts form for customer identification. A click inside the Contact Manager or Dispatch forms could bring up Microsoft Maps, allowing the dispatcher to direct our field technicians to unknown locations. Rich reporting gave real-time insight to the health of the business. C++ allowed me to create then, Active X objects which I could drop into Access. This all was cutting-edge technology in 1998 and to this day, I haven't seen any ERP application to match the ease of use or versatility of this application.


The business was rolling and it was time to get exposure on the Internet. My first foray into web site development was disappointing. HTML was restrictive and boring. Slow Internet speeds limited non-textual content. With DSL (and then cable) and CSS for formatting, I knew I could get what I envisioned. Due to my business demands and no interest in burning midnight oil, little time was allocated for development. However, I learned CSS and put together what I thought was a professional site. Admittedly, the code is not the cleanest. For expediency, much styling was done in HTML rather than in the external CSS. But, it gave me what I wanted. JavaScript provided for revolving images and PHP allowed videos stored on the Host server to be viewed using FlowPlayer.


See it here.

After I sold the business, I went to work for a company producing RF amplifiers. They were using LabVIEW to acquire test data for all products coming off the line, but had no way to analyze the collected data for it was saved in .csv files. First, I created a Schema in our Oracle 11g database containing all the necessary tables to hold test data, specific product data, Users, and Permissions. Since our database was of poor design with a single customer or product requiring multiple VARCHAR2 Primary/Child Keys and tables containing duplicate information, complex SQL containing REGEX was required. Once the stage was prepared, I set off to learn LabVIEW.


Though an OOP language, LabVIEW is graphical rather than textual. It took a month for me to wrap my head around the idea of VI's and "Wires". I built my own Sub-VI's that took the collected data and wrote to the database using SQL rather than LabVIEW's "dump and run" Sub-VIs. Management refused a Browser-based solution for Analysis; insisting on a Microsoft solution. For expediency, I again turned to Access as a front-end and using Automation, had it call and pass parameters to Excel for display of raw data. After this was complete I turned my attention to Repairs, which required a LabVIEW UI so technicians could pull customer data, purchase date, repair history, and previous Tech notes. After diagnosis, techs could browse parts used in the amplifier and drop those required for repair into a "Shopping Cart" where price was calculated. The tech then added labor which was calculated and sent the estimate to Inside Sales via email, eliminating a stack of paperwork that was not only a pain, but was prone to get 'lost'.


LabVIEW is different. I'm not sure it is the best software for data acquisition, though the native Sub-Vi's make it easy to say, sample a digital signal. A sequential, textual language perhaps is better for data acquisition because following logic within G code is a pain and the more complex the code, the more difficult it is to follow. Code is contained in VI's and they are made by dropping other VI's (Sub-VIs) from a Popup palette and "wiring" them together. The Controls palette is populated with switches, sliders, gauges, etc. all limited in both variety and functionality, but it is a drag and drop operation. However, a big bonus to LabVIEW, is that each While Loop in the main VI runs in its own Thread and LabVIEW takes care of the housekeeping. Ah, multi-tasking!