In Search Of Freedom

One of the things I've learned over the years is that most programming projects revolve around one simple core requirement: The storage and retrieval of information.


The co-worker/friend who (in the late 70s) gave me my first PC also introduced me to dBase II – a database program for the PC that stores and retrieves information. In very little time I had built a small business around writing programs based on dBase II. Eventually, my business grew beyond my ability to write and maintain my own software - so I turned to something else: An application framework that was based on dBase. Instead of writing applications from scratch, I could start with an existing application and modify it.


At that time (mid 1980s) there were several dBase application frameworks available. I chose to be a reseller/consultant for a product called SBT – which was an acronym for Small Business Technology (later became Software Business Technology, which was then bought by ACCPAC).


SBT was perfect for my needs – it was an application framework plus basic accounting applications that provided the foundation for any future programming project I might encounter. Although things started out great, in time I discovered that SBT had some serious flaws and limitations. I tried to share ideas to improve the application framework with the folks at SBT, but I was met with an attitude of superiority - they knew what was best and I was just a lowly reseller. My suggestions were ignored. That attitude frustrated me, but I remained loyal.


During that time I also supported and maintained accounting software (like ACCPAC and MAS90) that were based on other programming languages (Business BASIC). Eventually, SBT offered me the opportunity to be a beta-tester for an upcoming new version. I jumped at the chance.


I received top-secret versions of unreleased software to test. I ran the software through many tests - and I found a number of flaws. I reported the flaws to SBT, but the response I received was that same attitude of superiority I got in the past: I must be doing something wrong because SBT programmers are infallible. I was frustrated.


It was time to appeal to a higher authority. As a beta-tester, I had access to the project manager of the new version, so I forwarded my beta-testing conversations to him. His response? “We're too late in the development cycle to correct the issues you brought up.”


That made me decide to go back to writing my own software. To keep a long story short, I wrote two application frameworks – the first one in C++, and its successor in Visual FoxPro. Both versions met my needs as an application developer. In my efforts, I sought to overcome the limitations imposed on me by the commercial application frameworks I had tried in the past. My main goal in both frameworks was freedom – freedom to expand on a base set of functionality so that I could add new functionality with minimal effort, and freedom to invent new applications the framework had not anticipated.


The problem was, I ran into the same situation as before – my needs grew beyond my ability to write and maintain my own software. I started to realize something. What I really needed was the best of both worlds: be a member of a team of programmers working on an application framework, and be a user of the framework at the same time. The question was, how do I do that?


(To be continued...)

My Epiphany

February 14, 1995, 6 PM: I'm spreading carpet glue on the floor of our new retail space.

I had recently sold my business to an acquaintance who had been very successful with a number of local businesses. I was retained as General Manager. The problem was, the new owners moved the business to a new location (where they could "keep an eye on it"), but they wouldn't spend any money on improving the new location.

The new location was horrid. Seriously, if I was a drug addict, I wouldn't go there to score crack - I would be too afraid. I tried to tell them that the new space was unacceptable as a retail showroom/consulting space. They didn't listen. So, being the goal-oriented person I was, I rebelled and bought new carpet for the new location with my own money. And I planned on installing it myself.

My wife helped with the carpet installation. She was so faithful. She had endured the years of me working nearly 24 hours per day sitting at the computer trying to build our new business. She dutifully drove hundreds of miles picking up parts and delivering computers. Together, we transformed a single PC clone and my rudimentary programming talents into a $400,000 per year business with five employees.

But here we were - slopping carpet glue on a concrete floor on Valentine's Day.

That's when I had my epiphany. It was the evening of Valentines Day. I should have been having a romantic dinner with my wife. Yet, there we were laying carpet. Right then and there, a light clicked on. What had been my personal determination to make the business succeed suddenly seemed absurd and inconsiderate.

With a firm resolve, I decided that we will never have a Valentines Day evening like that again. From that day on, Valentines Day would be all about my wife!

I made the commitment. My wife was more important than my business.

A Brief Affair With Performance Optimization

When I owned my computer business, I was always trying to find ways to set myself apart from the large and ever-growing pack of so-called "computer consultants." Shortly after the introduction of the IBM PC, it seemed like everyone who owned one would print business cards and then go out and sell themselves as consultants - even though they didn't have any computer experience outside of their own basement. One of the ways I set myself apart from those posers was by offering superior performance - in hardware and software.

On the hardware side, I built and sold IBM AT (80286) compatible computers - but they were much faster than my competitor's 80286 computers. I used my electronics background to design fast systems. I carefully overclocked the CPU, I coupled RLL hard disk controllers with low seek time hard disks, I optimized hard disk interleave, and I installed a minimum of one megabyte of memory so the area above the 640 kilobyte DOS limit could be used as a disk cache. My computers cost about $100 more than my competitor's, but my customers understood why. Unfortunately, my competitive edge was short lived - it wasn't long before other shops in the area started offering similar systems.

On the software side I optimized code. Microsystems Journal ran a series of articles on optimizing assembly language code, so I spent some time trying out different ideas based on their concepts. I ended up with a toolkit of code optimizations that I could use in any language. Most of my small business customers were running accounting applications written in Business Basic (MAS90, ACCPAC) or dBase (SBT, Champion). Whenever one of those customers complained about a report or batch process running too slow, I applied my code optimization toolkit to the code and got it running faster. On rare occasions I would use my assembly language expertise to solve a performance problem (does anyone remember TSRs?).

Eventually 32 bit computers arrived with the 80386, and performance problems were easily solved with a faster computer. The consultant posers were going to school and actually learning the things they claimed to be experts in. I was losing market share. I started to blend in with the pack. I had to do something. I had to do something different.

I decided to go into the mainframe world. Why should I work in a world where computers cost thousands, when I could just as easily work in a world where computers cost millions? So, I enrolled in a school that taught mainframe programming - and while I was at the school I had the opportunity to work with an IBM System 370. The school taught COBOL, C, and Assembly Language - and it was in the Assembly Language course that I decided to use my code optimization toolkit.

From an assembly language standpoint, all CPUs are basically the same - the main difference is the mnemonics. Since I was experienced in assembly language programming, all I had to learn to pass the Assembly Language class was the 370's mnemonics. The lab assignments were trivial and I received perfect grades without trying. I was bored, so I decided to stir things up a bit. Instead of writing code the way the textbook dictated, I would use my code optimization toolkit to write very fast code that achieved the same results.

I'll never forget watching the instructor as he graded my first optimized lab assignment. He picked up his red pencil immediately - ready to mark up my "wrong" code. Then he paused, cocked his head, and put his pencil back down. After a few minutes, he graded my assignment and went on to the next one. When I got the assignment back, I saw that it received a perfect grade and a note: "This isn't what the textbook taught, but there is no doubt it would execute faster."

It turned out my instructor's "real job" was working as a lead programmer at TRW (now a part of Experian). At the end of the course I gave him my card, and shortly after I graduated he gave me a call. He wanted me to try my optimizations on some of their programs that were running a little slow. I made changes to a handful of printouts, got paid, and never heard from them again.

My plans to work in the mainframe world never panned out. Businesses started unplugging their mainframes and switched to LANs. I managed to pick up a few municipalities as customers though - they used me to integrate their LANs with their mainframes.

Nowadays there isn't much need for performance optimization. Computers today are very fast and very cheap. Today's 32 bit CPUs running at 2 GHz are 4000 times faster than the original IBM PC. Modern compilers do code optimizations automatically. Performance problems are solved with more servers.

My brief affair with performance optimization was fun and educational. I still put my code optimization techniques to work today - not in a way where better performance is a goal, but rather as a way to avoid writing sloppy code.

My First Computer

Like your first love, you never forget your first computer.

In the late 1970s, I worked for Beckman Instruments as a QC inspector in their hybrid microcircuits department. Hybrid microcircuits are very complicated things, so they had to be tested by computers connected to racks of testing equipment. The QC lab was filled with computers (mostly DEC PDP-11s) and innumerable shelves packed with electronic testing equipment – all of it the finest gear money could buy. It was an electronic technician's heaven.

I'll never forget walking into the lab on my first day of work. On the back wall there was this one equipment rack that stood out. It was sleek, modern, imposing. It had an angelic glow. I think I heard a choir when I first saw it. On a desk next to the rack was the computer that controlled it – a desktop device that looked like a large calculator. Eventually, I was allowed to use it - and that's when I fell in love.

It was a Hewlett-Packard 9825.

As a QC inspector, my job was to operate the HP 9825 - not program it. I didn't know anything about computer programming, but I wanted to learn. I wanted to learn because I wasn't satisfied with operating the 9825 - I wanted to explore it. I wanted to get intimate with it. So, on every 15 minute break and lunch break I would read the 9825 manuals. In time, I got a good understanding of the computer's language, but I didn't know how to write a program. I needed a printout of an existing program to use as an example, but there was no way for me to get one without asking one of the in-house programmers for it.

The programmers in our department were a group of about 4 guys. They were brilliant because they had to know more than computer programming - they also had to know electronics. It wasn't enough to know how to construct a for-next loop - you also had to know Ohm's law, fast Fourier transforms, frequencies, etc.

In that group of programmers were two personality types – the territorial ones and the not-so-territorial ones. I approached the not-so-territorial ones about my desire to program the 9825, and asked if I could see a program printout. They gave me several. I pored over the printouts and eventually wrote a few routines of my own that manipulated the computer's display. The day came when I demonstrated my routines to the programmers - they were impressed. I continued learning and exploring. As long as I wasn't messing around with their programs, the programmers were happy to answer questions and give advice. But then things changed...

I was working with the 9825 one evening after the programmers left work. A test that needed to be completed before the end of my shift wouldn't run – because the program was stuck in a loop. It would ask the operator a question, and no matter what was entered, it would keep asking the same question. I agonized over what to do. I knew I had the capability to fix the broken loop, but I also knew that doing so might destroy the friendly relationship I had with the programmers. I reasoned with myself, “It's a simple one-line fix – it doesn't alter anything important. Surely they will be okay with it.” I fixed the program, completed the test, and then left the programmers a note about what I did.

My solution didn't go over well. The territorial types used my actions as a reason to lock the source code so that no one except them could alter it. Most of the programmers became less supportive of my efforts to learn computer programming. Except for one – he gave me a personal computer so I could continue learning at home. He also came to my house to help me learn other programming languages. In time, I started doing side programming jobs, which later became a thriving full-time business.

I've worked in all kinds of environments, from PC to mainframe, from single user systems to complicated enterprise class client-server systems. Through it all I have never forgotten my first love – the HP 9825.

Refactoring

When I was first introduced to Algebra, it didn't go well. Even though mathematics had always been an easy subject for me - producing straight A grades - there was something about Algebra that just didn't click. Despite my best efforts to do well at it, I failed the subject and had to retake it the following year. Fortunately, the following year was different - it clicked, and I was back to making straight A grades again.

Learning Algebra was like exploring a whole new world in mathematics - I was fascinated by it. There was one aspect of Algebra that had me hooked - reducing equations. I had a natural talent for evaluating complex equations and reducing them down into their simplest form. I thoroughly enjoyed doing it, I was very good at it, and I couldn't get enough of it. It was like crack.

When I became a computer programmer, I found a new (and similar) natural talent - refactoring. I would look at long, complex computer code and I would reduce it to its simplest form. In procedural languages I would create function libraries, and in object oriented languages I would reorganize classes and class methods. All of it came naturally and without any formal training in the subject.

I always wondered if I was doing it correctly and if there were other methods I could learn, so I picked up Martin Fowler's book on refactoring. It was worth reading. I agree with him that bad code has a smell and that some refactorings come naturally. I now have names for the methods I've used in the past, and I also have new methods I never thought of. After reading the book, I looked over some of the code I refactored recently and I was pleased to learn I did it "right" - there was nothing suggested in the book that would make the code simpler or better organized. I'm not trying to boast, I'm just saying it feels good to know for sure.

...

Sometimes I find myself getting frustrated while working on a software project. When that happens, I put the project on the shelf for a while and do something fun to occupy my time until I'm ready to get back to it. What's the "fun" thing I end up doing most often? Refactoring smelly code. I can't help it. It's like crack.

Introduction

I'm an IT Manager/Computer Programmer for a company that builds homes. I've been programming computers since 1978. The programming languages I've used are: Basic, Visual Basic, xBase, COBOL, PASCAL, Assembly (both x86 and IBM System 3xx), C, C++, and Java. The platforms I have worked on include DOS, Windows, Unix, and IBM VM.

I owned and operated a computer retail/service/consulting business for over ten years.

For a time I was Technical Editor of Coast Compute Magazine, and a contributing writer for Programmer's Journal.

This blog was created to be a place where I can talk about one of my passions - computers and computer programming.