Back Draft
Valentines Every Day
By Jonathan Goodyear
Another new year has come and gone, yet I ll bet you ve already broken most of your New Year s resolutions. They always seem to be more effective in theory than in practice. The next important holiday is Valentine s Day. For Valentine s Day, I always buy my wife Joy a nice gift (some jewelry, perhaps), give her flowers, and take her out for a nice dinner. I m careful to be nice to her all day, and I wouldn t think of spending any non-working time on my computer (which can be tough).
Every year, however, Valentine s Day brings with it a bit of guilt (though Joy never says it). Why do I need a designated day to prompt me to be extra nice and give flowers? After all, that s the kind of behavior that I should be presenting all year. This year, I m going to make a serious effort to make every day like Valentine s Day. I won t call it a New Year s resolution, though, because merely labeling it as such virtually dooms it to failure.
There are a few behaviors in our daily computing lives that should be done a lot more often than most of us do, as well. One of them is backing up our files. Most of you probably have some form of back-up mechanism, whether it be burning DVDs or using a utility to create a copy of your files on a file server in your office or home. What if your office or home burns down, though? It s not a scenario that you think about very often, but you should. I d wager that most people whose offices or homes burn down didn t think it would happen to them.
To satisfy my healthy paranoia of losing my data, I back up my personal and company files to a local file server every night. Then, once a week, I upload my data to a dedicated server at my hosting facility, ORCS Web (http://www.orcsweb.com). They, in turn, make their own backups of my files. Nothing short of a nuclear holocaust is going to destroy my data, and that s the way I like it.
Another thing that we should do more often is use source control for our code. Right now, you re probably saying to yourself, What s this guy talking about? I use source control software. Right, but how often do you check your files back into the repository for version stamping? When you are working on a section of an application by yourself, it is easy to forget to check the files back in after you add and test each feature. If all goes well, you never know the difference, but if something goes wrong, your only option is to roll back all the work you ve done since your last interaction with source control. Usually that means making a copy of your code and manually re-integrating the stuff that works into the recovered file. That s no fun at all.
To prevent that situation, I check all my files that are compilable back into source control each night. That way, I have multiple restore-points to leverage if I need them. As a point of note, you should even use source control for small projects and utilities, documentation, diagrams, images, etc. Source control isn t just for large code projects. It can be a really useful tool for tracking the changes of these other supporting documents to the software development process. Of course, you ll want to add appropriate comments as you check in each file to remind yourself about what you changed (especially for non-text file formats that can t be compared side-by-side and eye-balled).
Speaking of comments, a task that almost every developer pushes off his/her plate until the very end is documentation. While it s good to have real functional and technical specifications to work from, many times that is not a reality. We may or may not have control over that part of the documentation process, but one part that we do control is code documentation.
No matter how good your memory is, you re not going to remember all the details surrounding your code when you come back to maintain or enhance it a few months down the road. If somebody else needs to do the maintenance, then you re really going to be in trouble. The argument that your code is self-documenting is complete garbage and is usually used by lazy programmers. It may be very easy to tell what your code is doing, but that doesn t give any indication as to why you did certain things. The why part is the most important aspect of code documentation. It s the documentation that prevents future developers from correcting or optimizing your code and introducing preventable bugs.
To remind myself to document my code, I write out a series of one- or two-line comments before I write a single line of code. This way, I literally script out the functionality (in the theatrical sense). As a result, I make fewer errors of omission, and I don t have to swing back later and add comments that are never as complete as if I do it up front.
So there you have it. Just as you should try to treat every day like Valentine s Day, you should make an effort to back up your files more often, effectively use source control software to track your entire software development process (implementing your code in stages), and document your code as you are writing it. Behavior modification is always tough. Most of us need a powerful motivator to institute change. Let disaster prevention (instead of the disaster itself) be that motivator for you.
Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, FL. Jonathan is Microsoft Regional Director for Florida, a Microsoft Certified Solution Developer (MCSD), and author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at http://www.angryCoder.com.
