The Case for Source Code Backup - Desktop (Part 1)

As a software engineer I tend to end up with many lines of source code that change over time, and projects that I want to preserve and update. I've tried different methods of keeping everything in sync. Everyone starts up with strategies that they swear by until they fail them. I'm going to illustrate why I needed source code hosting, and the lessons I learned along the way. This post deals strictly with backups on the desktop in a pre-2000 era. This post is a 3-part series on backup and version control. For modern desktop backup practices, skip this post and go directly to the last post in the series (which I haven't published as yet).

1987: 5¼" floppies and a TRS-80

In my defense, I wasn't yet ten years old at this time, but I was busy writing code on my very own Tandy TRS-80 personal computer. I know all the TRS-80 fans are probably perking up by now. After writing every program in the Extended Color Basic manual that was included with the ‘Coco’ I moved on to trying out some of my own programs. At the time I didn't know anyone else with a Tandy computer, so all my programs were written to a stack of 5¼" floppies that I had with the computer.

As anybody who remembered those times can tell you, these disks proved extremely unreliable. So much so, that when I tried to read them several years later, all my code was lost. Good for me, I'm actually grateful my programs from my early years are lost forever. They were some horrendous games with flashing block graphics and awful musical tones. What did I learn from this, next time I needed to write code, I should use some reliable storage medium.

1994: The stack of 3½" disks

Fast forward to my O'Level Computer Science project in high school, I'd now learned the basics of computer programming, and I could program circles around almost everyone in my school, except for 2 computer science teachers. There were a few of us in this class who were grasping the technology at the rapid pace it was being developed, and the slow pace we could grab on to it in Trinidad at the time. Buy now the 5¼" floppies were unceremoniously replaced with high capacity 3½" floppies. I actually don't know why we called them floppies still, as these were small disks in a hard plastic case. A disk could hold 1.44MB of data, fit easily in a shirt pocket, and at the time that was a lot of code to be walking around with.

For O'Level Computer Studies, I was required to complete a year project to design and implement a software application in the language we were learning at the time. Given a full year, I had completed my final year project shortly after Christmas, and I had the working BASIC program on my floppy disk. I didn't own my own personal computer at the time, so the only copy of my program resided on my 3½" floppy disk. One of my good friends at the time had also completed his final year project after Christmas, and was eager to show off his coding skills. He had written a program that would read another software program and count the total number of lines in the program.  As part of the adventurous group, I gave him my diskette with the only full working copy of my program to count the number of lines in my program. Strangely enough when he ran it on my program, the result was: 0. For the initiated, there was a problem in the code between LINEIN and LINEOUT. When we opened up my program to see what was wrong, there was a strange number, which we later presumed to be the number of lines of code in my program. Unfortunately, that was now all that was left of my program.

I could now, either restart my program from a backup diskette, made from over a month ago, or use the adrenaline of everything lost to start my project over from scratch.  Lesson learned, I was now creating 3 copies of the program every time I saved it. I went on to create a different project and win the award for best O'Level Computer Studies project for 1994, something I went on to do again at Advanced Levels in 1996, albeit without the drama of losing my code again.  I also learned to never let people experiment on my code again.

1999: How my hard drive failed me

So I learned my lesson about removable storage. Now fast-forward to my final year Computer Engineering project in 1999. I was writing a Java Servlet-based course management program.  Again, this was now my year-long Electrical & Computer Engineering project. I had gone through most of the year making slow but steady progress toward completing the application from design through implementation. I was also steadily documenting the application as I went along, so my design documentation was in-sync with my development.

With one month left to go before submission of the project, the impossible happened.  My hard drive crashed. This was the first hard drive failure that I'd ever had, and the crash took with it my final year undergraduate project, source code and documentation.  8 months of work and research was now gone.  University isn't high school, you can't tell you teacher that your hard drive crashed.  So I started over a brand new project the very next day with approval from my supervisor, who I'm sure was ready to write me off as a lost cause. When it was all over, I also ended up winning the prize that year for best final year project in Electrical & Computer Engineering at the University for 2000. Although my loss of data had an incredible ending, I'm not encouraging anyone to follow suit. I now have 4 hard drives in my desktop computer, I do RAID and weekly backups which have saved me from the 6 hard disk failures I've had since. Redundancy has been a great thing.

More to come

There are more lessons that I learned, and I'm setting the stage for some best practices here, but I'm also taking you through my own journey as I got to these best practices. In the next post in this series I will discuss networks and server-based backups.