Professional Interests/Abilities

Overview On this page, I will attempt to describe the kinds of knowledge that I possess, and the kind of work I can perform. This is not a resume: in a way, a resume feels a bit limiting because my interests and knowledge far exceed the computer arena within which I make my living. That is why I've included a Personal Work History where I describe all the different kinds of work I've done in the past. To quickly jump to a topic, click on one of these names, or you can simply scroll down to each topic: Networks - A History Networks - Current Standards Policies Programming Resume Personal Work History qcsi-Systems(formerly Quadrant Computer Systems) Networks - A History My first experience with networks dates back to about 1980 when I had to set up a Corvus network for the University of Texas Health Science Center, in the old Prudential building, across the street from M.D. Anderson Hospital. It had a 5Mb hard drive at it's core, and served about 3 users. It seems almost like a joke, now, but it was fascinating at the time. Shortly after that, I installed a 3Com network for a small oil company on I-45 near the airport. That was much more impressive, and much more functional. It served about 10 users. Shortly after that, I received some training with Novell Netware and began to install networks all around the city. The most noteable installation was for the Houston Rockets basketball team, in the bowels of The Summit, and for various groups at Texaco in downtown Houston. There were also law firms, employment agencies, management groups, security firms, and on and on. All this doesn't sound too impressive now, but this was in the early 80's. I worked for the only computer store in Houston that -- at that time -- provided corporate level support. It was a radical idea back then, and we really hummed along selling and supporting all kinds of equipment and installations. With this background, I then moved on to another store where I was the Director of Service, Support and Training. This, too, was a gutsy move and reflected the early days of networks and new concepts in how computer service and support should be executed. I felt I was relatively successful in my tasks, but I kept running into the "sales mentality" of sell as much as you can by the end of the month, no matter what. The "no matter what" would always come back to burn me, for I would end up having to correct the mistakes of the sales staff. A year later, I had had enough, and found a job in the corporate world. My strong suit for my new job was, of course, networks, and it came in handy. The marketing group needed a network so we installed a Novell S network, a star bus, with proprietary servers and cards. I was an advocate of generic systems and suggested we use standard PCs as servers, but that idea was pretty radical back then, and I was over-ruled. The mainframe mentality compelled my superiors to prefer proprietary and one-stop solutions. In the long run, however, my advocacy paid off. The Novell network soon grew to 3 servers and was becoming burdensome to handle. We knew this network would, in effect, serve as a pilot project for a company-wide network... possibly a corporate-level Wide Area Network... so we installed the hardware, configured the software and developed standards from the outset as if it were going to be installed everywhere. (See the section below on Standards and Policies.) But even with standards, the Novell network was getting hard to handle, and we were appalled with the idea of adding more and more servers. The administration overhead would kill us. So we looked around for a better solution. What we came up with was Banyan VINES. Even at that moment early in their history, we could see where they had significant advantages over Netware. The StreetTalk naming scheme was brilliant and the ability to hook up multiple servers without any effort was incredible. We even sent a Banyan server to Kansas City to test the wide-area-networking. We set aside a full two days expecting the attempts at connecting it with our Houston servers to take that long. It took two minutes! We were stunned and thrilled. It didn't take too long to replace the 3 Novell servers with 1 Banyan server, including all structures and access rights. I managed it by loading both the Novell shell and the Banyan shell on a Compaq transportable, than simply doing copies from one drive to another. Access rights took a bit longer, but I had set up the subdirectories with the proper access rights ahead of time, so when the files were copied over, they acquired the default access rights. The switch was complete and was to stay that way for over 10 years. Networks - Current PC Support I began my initial position with the company in PC Support, but it quickly metamorphed into Network Support. To this day, however, if a PC Support question comes along that no one else knows the answer to, it always comes to me. I have often joked that, if I were named CEO of this billion-dollar company, I'd still get calls from users asking how to format a floppy. Network Support Since we were a fledgling network, it wasn't just a small, cubby-holed position of Network Support, it was design, install, wire, configure, load, administrate, etc. It was everything. As Network Support, I was called upon to provide installation of hardware components, from the UPSes all the way through BNC connectors, network card configuration through specifying backup tape brands. Network Administration Administration was a bigger job than just adding new users, or changing passwords. Information about the network was critical in making sure it stayed healthy, so programming skills were necessary to write utilities that would extract the data we needed. It would be foolish to run a network in a reactive mode: proactive judgements had to be made to ensure the stability and long-term viability of the network. Network Design Luckily, my earlier days of installing networks provided OJT on what can go wrong if the network isn't designed properly. (Not to mention the issues of dicey installations!) So, our first network was a broadband system (a system I did not recommend because of the high tuning costs) which spanned only about 50 users. When we moved to a larger building, it went from a small, almost manageable configuration, to a large, unwieldy and expensive project. We did the best we could with the technology, and created all sorts of strategies for dealing with weird problems -- which we got our share of. Eventually, we moved to Token-Ring. Given the physical size of the building, some inventive configurations were required to make it all work within the limitations of token-ring wiring. Bridges were used until the router technology made the collapsed backbone a possibility. Now, FDDI links provide super-fast backbone raceways for the high server-to-server traffic. The wide-area-network was upgraded from analog to digital microwave, against my objections. I would have rather seen the money go toward running fiber optic between stations. But by this time, most of the company network was segmented into several discrete areas of responsibility, with no accountability between the groups. We had gone from a 3-server, 10 user Novell network to a 70-server, 3,500 user, VINES wide-area-network covering more than 20 states. Network Special Projects The small utilities I was writing during the early network administration days were providing me with a solid background in network systems programming, so it didn't take long before larger projects came my way. In fact, if something was network related, and no one else could do it, it fell on me to figure out a solution. A virtual sign on my desk: "The Technical Buck Stops Here". Standardizing log-ons required utilities that interacted first with DOS, then with Windows and Windows NT. Network based backup routines; administrative tools; network e-mail systems and utilities; network-centric resource access, including optical drives, CD-ROMs, scanners, fax, etc.; metering network software; including field offices (with slow communications links) in network software distribution. Glue; SQL; Notes; document management; middleware Current projects involve writing DLLs that other systems can use, e.g. PowerBuilder, Visual BASIC, WinBatch, Access, Delphi; implementing Notes systems and writing utilities to provide an interface between Notes and other systems; writing a document management system, then re-writing it for Windows; developing CGI components for Web servers; developing commercial Web pages; writing wide-area-network distribution processes for mission critical files; and the always needed network utilities... Standards Policies Standards Advocacy from Day-One When I accepted the job as Director of Support, Service and Training with the computer retail store, it was patently obvious that having standardized systems, parts, manuals, and support policies would make the difference between getting the job done, and letting all kinds of things fall between the cracks. When I started in PC and Network Support in my corporate job and was charged with coming up with network directory structures and log-in procedures, the idea of standards was again a central theme. We knew we had to get it right at the very beginning, and develop a system that could get as large as it wanted and still be workable. It had to make sense. So, one of the fundamental tenents developed more than 10 years ago was that with standards, you can accomplish a lot more with a lot fewer people, and still provide the necessary services and support to the end-users and clients. Software standards In addition to network standards, directory standards, training standards, and and support standards, some kind of structure for what software tools were to be used was necessary. Even 10 years ago there were many products in each software category that would adequately fill the bill, so we evaluated what was available, selected the best all-around product, and then allowed only that product to be purchased. Hardware standards It also made sense to try to standardize the hardware components as much as possible. This sounds easy but with many groups and departments wanting to purchase equipment with their own money, and set things up their way, it came down to policing and top-level management support. The big-whigs had to understand that having everyone go in their own direction was going to affect the bottom-line, for years to come. Once they understood that, we got their full support. We then were able to carefully test PCs in our internal lab, and eliminate all but one or two vendors from consideration. Then we discovered that keeping it down to one or two vendors often wasn't enough. Since the vendors would change components without notifying anyone, we could be and were often caught looking bad. This became even more serious when the vendor would change the BIOS and the change either made it more difficult, or impossible, to make our systems work. The funny part of all this is, we had a glowing reputation among our corporate brethren as having rock solid standards, but we felt they were still too lax. Network standards As described above, subdirectory structures were standardized even before there was a network. We then extrapolated those structures on to the file servers. Other standards that had to be created, designed and implemented dealt with access rights, resource access to mini- and mainframe sessions, file and print service configurations and naming standards, user login standards, network card configuration standards, and network documentation and reporting standards. Writing policy At some point, we had to start documenting our standards policies. Almost from the outset, we recognized that one of the responsibilities of having a standard was to declare it, defend it and promulgate it. To anyone who has never had to write actual policy documents, the task seems easy. But like everything else, it can be door poorly, or done well. It required creative thinking skills as well as analytical and technical thinking skills, not to mention good writing skills. The bookcase was full of mainframe manuals, 5 inches thick, as good examples of how NOT to write policy. In the end, we learned that these documents are "living" and must be kept up as the network and its policies change. Preaching to ABUI As an early implementer of a relatively large, Banyan VINES network, we were sometimes looked upon to provide enlightenment at the yearly Association of Banyan Users, International (ABUI) conference. As it turned out, many of the standards and policies we had developed were universal in nature. So, over the course of many conferences, I gave several talks on what our standards were, how they worked, and lessons we had learned. Interestingly, I found out that a small entrepreneurial group took many of my ideas and made a living providing consulting services to other companies. Kind of a back-handed compliment. (In fact, this very essay would work as a good overview to the types of strategy that medium-to-large businesses SHOULD use in their approach the networked systems. Oh, and, YES, I'm available for consulting! :-) Transparency Philosophy One of my brightest ideas and philosophies was also my biggest undoing, so to speak. My concept of how a traditional Information Systems group should work, was to provide service to the end-user but be a transparent to them as possible. I worked feverishly over many years to implement systems to users that allowed them to push a button or click on an icon, and their work was done. They didn't have any idea of how complex the underlying system was, nor did I want them to know. I felt like the information resource should be as much in the background as possible, since it did not directly provide any income for the corporation. This was also a 180-degree turn-around from mainframe philosophy, the ivory tower syndrome where the user had to bow-down to the programmers to get any information out of the computers. While this philosophy (at the time) was new and revolutionary -- and INHERENTLY the best philosophy for information resources -- it had one major problem: if you succeed too well, you become invisible. If you're invisible, you no longer can get the attention of management; they think everything is working just fine and you don't need any more money, people or other resources to continue to do the job. In fact, they often start thinking: "Why are we spending so much money on these guys? They never do anything. You never see them. They just soak up money." So, my "Transparency Philosophy" works only if the MIS manager/VP/CIO/whatever is politically saavy, and will constantly "sell" upper management of how well that philosophy is working, and why the MIS group needs to be supported and maintained. Programming History of languages/systems I know... Roughly in the order I learned - Hard-wired programming (circa 1969) on IBM sorting, collating and printing machines, FOCAL, COBOL, RCA Spectra 70 assembly, IBM 360 Assembly, FORTRAN, 6502 assembly, AppleDOS, UCSD Pascal, MS DOS, MS BASIC, dBASE, Turbo Pascal, MS C, Modula-2, Clipper, PowerBuilder, Object Vision, Borland C++, Delphi, Delphi, Notes, WinBatch, HTML, JavaScript, Java, Vitria BusinessWare... Toolkits Where do I start? Most of the PC languages have had 3rd party toolkits you could purchase to perform any number of functions. I began using utilities with dBASE II and dBASE III+, but started using actual toolkits in earnest with Clipper, then C, Pascal, and now with Delphi and Java. DLLs When Windows 3.x came along, having functions in DLLs that were easily callable from a higher level langauge was wonderful. It was better than dealing with .OBJ files, and allowed more of a cross-language capability. Then I realized that creating them wasn't too difficult and started that in 1993. Today it's still a powerful tool for creating low-level or system-level functions to higher level languages. SQL Since most of the tasks I was assigned to do had to do with system-level and network-level functions, I didn't get into high level programming too much. But I did set up a server specifically for SQL Server, learned how to implement it over the network, and learned about the lower-level calls. Recently (June 2000), I've even created an extended stored procedure, which is a process for extending the capabilities of Transact-SQL. Networks Network programming is now my "bread-and-butter", usually cranking out 2 or 3 utilities or applications per week, each having some network function call or another. The Internet Creating programs for the internet is a little different, but most of the work isn't more difficult. Protocols (most of which are surprisingly "old") such as HTTP, FTP, and SMTP are used to communicate between programs, between programs and databases, or simply to create a user-interface -within-a-browser. I've created EDI systems using FTP and encryption algorithms, automated email deamons that receive data which is then processed and stored in a database, SMTP processes that allow pagers to be called via a web page, and many other processes. Resume Click here to view resume Personal Work History -- Non-Programming Mettle -- Someone once asked me, if I lived in a purely non-technological society, how would I make my living? The answer may reveal more about me than anything else you might read here. I would say I would be a writer, or -- if that was not quite acceptable, I would have to say: a carpenter. I not only like creating things, but I like the process of creating things. I also like to be able to see a finished product... you have to be competent when your wares are on display. Here are some of the non-programming things I have done with my working life: Writing Writing is a "first love." I do it primarily because I enjoy it, but I've also had a lot of training in school, including the development of and participation in a Science Writing course at the University of Houston. I've used that skill many times, particularly in the last 10-15 years, writing and developing catalogs for scientific instruments, PC journal articles, network magazine articles, and writing training manuals for PC classes. Heck, I've even been published in some SCUBA journals! Training Over the last ten years, I have developed and taught many classes in PC applications, such as Lotus 1-2-3, DOS, dBASE, Word Perfect, networks, and communications. Photography My interest in photography started around 1970 when I watched my brother dabble in it. Not long after that, I started to learn about the chemistry involved. Before long I was doing darkroom tasks, and printing my own photos. In 1973, while in the Navy, the ship upon which I was stationed was ordered into the Red Sea, which no U.S. ship had done 12 years previous. Although I was merely a personnel manager (Personnelman) on the ship, my knowledge of photography got me temporarily assigned to a mission where I was to take photos of the military armament staged at the entrance to the Red Sea. Later, when I was in Iceland, I was under the tutelage of an "old as the hills" Navy photojournalist. He taught me more about darkroom work, and more about journalistic techniques. I spent most of my time off in the base darkroom. After leaving the Navy, I first found work as an apprentice for a camera repair shop. I then got some darkroom work which soon accelerated into photographer. I also found part-time work as a freelancer. It was wonderful. I was doing something I really wanted to do, learning new things all the time, meeting new people. But in 1980, I got tired of being poor. So it all ended when I left the photography field to pursue the almighty dollar. -- Darkroom In a lot of ways, I think I enjoyed the darkroom work more than being a photographer: I worked alone, I had to be creative, and I had to have great skill (or it was obvious!). For about a year, I spent everyday in a black-and-white darkroom. Later, I would spend time installing, maintaining and processing color film and print machines. I even got an early hand into computer augmentation of images, but it was quite crude by today's standards. -- Freelance My least successful work was doing freelance photography. It's hard work, you never get to rest, it's hustle, hustle, hustle. You have to be 98% salesman, and 2% photographer.. not my cup of tea. I much prefered the quiet darkroom work. But, to make a living, I took photos primarily of babies, pets, and youth baseball teams. More interesting, I sometimes got work doing food photography, as well as portraits. -- Scientific/Medical I worked for M.D. Anderson hospital first as a darkroom technician, but then later doing medical photography (mostly pictures of patients), but my final assignment was doing scientific photography. This was exciting because we often had to come up with our own way of doing things. Sometimes that meant a different set of photochemicals, different temperatures and/or times, different techniques with the camera or copy board, and a different mind set (today, we'd call it "thinking outside the box").. We sometimes constructed huge, um, gizmo's, just to hold an object in place, or to hold lights at special angles. It wasn't all fun... our bread-and-butter were the diazo slides for the doctors lectures. But it was sometimes worth the wait for the good stuff when a doctor walks in and says he needs some silohuettes of an eyeball, and plops it down on the desk. Great stuff! Camera Repair Repairing cameras was a very interesting (if extremely poor paying) enterprise. I apprenticed under several excellent technicians, and found I could pick it up pretty easily. It was a small shop, and we sat around a long bench and we'd chat all day about various things. It makes me laugh to think about it now. In a way, it was like sitting around playing cards all day, and gossiping, telling jokes, discussing the news, and each others lives. Of course, we were also consumed by the unending problems and variations of problems that you encounter when fixing the incredible variety of cameras we were given. (This was just before cameras starting going electronic.) It never enriched my wallet, but it was an interesting environment. I also learned to respect the engineering and optics that goes into the modern camera. qcsi-Systems(formerly Quadrant Computer Systems)   My consulting and contracting firm is qcsi-Systems (formerly Quadrant Computer Systems). It was formed in 1985. Click here to view the qcsi-Systems page.