Maybe it’s because I turned 40 for this year; maybe it’s because I’ve realized I’ve spent nearly 30 years with computers being a central part of my life. But for whatever reasons, I’m feeling particularly nostalgic and my mind is drifting back to my early days of computers and software development. I’ve seen a lot of changes since that first day when I walked into a Radio Shack and was immediately drawn to the Model 3 computer on display there. So for no other reason than I’m feeling sentimental, I’m going to take a walk down memory lane.
When I was a kid in the early 80′s, “home computers” were becoming more popular and I was chomping at the bit to own one of these incredible machines. I begged my parents for one and my persistence was finally rewarded with a TRS-80 Color Computer. But one computer wasn’t enough. I had to play with every computer I could get my hands on. I’ve used and/or written code on every Tandy machine made since the most awesome Model 3′s; Vic-20, Commodore 64, TI-99/4A, Atari 400 & 800XL, Amiga 500 & 1000, Timex Sinclair, Apple II, IIe and IIc.
Not long after getting my first computer, I learned that I could connect with computers around the world through this neat little device that people were calling a “modem”. I had to have one of those too and my parents finally relented. After hogging the household phone line and nearly deafening my siblings with the modem’s screeching sounds, my parents gave in and bought me my own phone line. I was now free to explore the world through my computer.
- I ran a BBS. With a 300 baud modem. I recall how awesome it was to upgrade it with my sweet JCAT 1200 baud modem.
- I wrote my own BBS software that at least a few other sites in Dallas used.
- I recall how important “Hayes compatible” was. I took pride in knowing the entire AT Command set.
- I remember XModem, YModem and ZModem protocols. I wrote my first XModem implementation in 6809 Assember.
- I had a subscription to CompuServe. Or Compu$erve as everyone referred to it.
- I remember when FidoNet was the coolest thing around.
- I remember writing war dialers.
- I remember phreaking. I also remember that when the Computer Crime and Abuse Act was passed in 1986 it scared me enough to stop my practice of using software I wrote to find and steal MCI long distance codes to fund my long distance BBS habit.
The early-mid 80′s were a great time to be a kid with a computer. Most of society still looked at these funny machines with skepticism, but we started to see our weird culture start going mainstream. Magazines, TV shows and even movies began to focus on our little world.
- I remember typing in programs that were published in magazines like Byte and K Power.
- I never missed an episode of “Whiz Kids”. I wanted my computer to talk to me the way RALF talked to Ritchie.
- I still remember where I was when I saw the commercial for the movie War Games. I begged my mom to take me until she did.
- I remember seeing the Apple 1984 Superbowl commercial live and thinking “Whoa! I gotta play on that!”
- I remember going to the mall and seeing Dillards (of all places) selling the first generation Macintosh. The employees would shoo me away when I would plant myself in front of it for hours.
- I owned a light pen and remember thinking how cool it was.
- I remember using an IBM PC Jr and that awful, awful keyboard.
Like any kid at the time, I was into video games. I learned how to control the rudimentary graphics on my various computers to write some really awful games. But nothing compared to some of the cool games available back then.
- I spent hours playing Bard’s Tale on a C-64.
- I played text-only adventure games from Infocom such as Zork and Planetfall.
- I wrote my own adventure games in BASIC. It saved your progress to cassette. High tech stuff.
Not surprisingly, my early 20′s found me making a living as a developer. No fancy GUIs back then. The mainframe still ruled and MS-DOS was the lingua franca of the PC world. My first job gave me the opportunity to work with everything from ancient systems to new fangled operating systems like Windows and OS/2.
- I wrote code to run on IBM 360, AS/400, VAX/VMS, Unisys A-Series and even toyed with a UNIVAC 2200.
- I was paid to write production code in Assembler, Algol, Cobol, C & C++, every flavor of Visual Basic including VB DOS, Access, dBase, FoxPro, Clipper, GW-Basic& QBasic
- I wrote TSR programs in Assembler for DOS.
- I wrote printer device drivers for some of the first version of Windows and OS/2.
- I worked on mainframes that still used 3340 Winchester drives.
- I used 8 inch floppy disks. In the 90′s.
- MASM 6.0 was my tool of choice for many years.
- I remember having to be concerned with extended and expanded memory under DOS.
- I learned entirely too much about Netware and worked towards gaining my CNE.
As Windows gained adoption, I took it upon myself to learn this new OS from the inside out.
- I bought several books on the Windows API and taught myself how to write a Windows app in C with just the API.
- I remember getting the HUGE box that contained Borland C++ 4.0. I learned OWL and Turbovision.
- MFC came along and I began a long, sad journey of using MS development tools.
- I wrote VBXs and OCXs using Visual C++.
- For kicks and giggles, I wrote a fully functioning Windows app in Assembler just to prove I could do it. It was the last major Assembler code I’ve written.
After spending years working with Microsoft technologies, time has moved on and today finds me writing Ruby on my Mac and re-discovering Linux which has re-kindled much of the hacker mentality I had when I was a kid pushing buttons to see what it would do. I’ve seen a lot and I’ve learned a lot over the years. I’ve seen countless technologies and fads come, and I’ve seen ‘em go just as fast. But one thing that has never changed is the excitement I still get when I figure out something new; when I get the computer to do what I want to do. 30 years later, it’s still the same feeling.
Comment Perjury
Recently, I was re-factoring some code with our lead developer and we were looking into how a particular method worked. My first step was to read the comments I had oh-so-carefully placed in there years before when I originally wrote the code. Armed with the knowledge I left there years before, we set out to add some new functionality.
How many of you already know how this is going to end? Well, for those they don’t already know, it didn’t end well. The code behaved nothing like what the comments said. Over the years, the code had changed. But the comments had not. So I ended up wasting time trying to unlearn my preconceived notions about how the code worked.
Our lead developer, Sean Scally, is not a proponent of comments and has been on a mission for years to curb the practice of “undocumentation”. He feels that the code itself should be clear enough for the developer to understand what the code is doing. If it isn’t clear, then refactor it until it is. After we got turned the wrong way because of my out of date comments, he smugly joked about my “comment perjury”. But he was right. My comments were lying to us. They were well intentioned when they were written, but most developers, myself included, rarely go back and update the code comments.
So now, every time I feel the urge to drop some comments to explain what the code is doing, I take a look to see what I can do to make the code a bit clearer. One of the best things I’ve found is to use the Extract Method to pull a code fragment into its own method, where the name readily explains what the code fragment is doing. Unit tests are another way to document your code without comments. In our business, the business rules can be fairly complex and change frequently. Trying to write comments that explain this logic is fraught with peril. (As I’ve learned) It’s much safer to have unit tests that readily demonstrate what the business rules are. As the rules change, you update your tests then update your code. No need to remember to update that big block of comments that nobody bothered to read anyway. And you get the added benefit of having your code under test coverage.
As in all things in life, moderation is key. I still hold that a properly placed comment can make a world of difference in understanding the code. But they should be used carefully and judiciously and only after other ways of documenting the code have been exhausted.