Archive for: February 2009

The stories have already started about President Obama that the honeymoon is over.

• Nominated cabinet members have tax problems.
• Buy America will start an international trade war.
• Afghanistan will be the new Vietnam, or the new Iraq.

Democracy is a messy process, and this is not the end but the start of the Obama presidency.  When the going gets tough, the tough will need to get going.

I use Mozy for my offline backups and I am very pleased with the service.  I moved to Mozy because my previous service did not support external hard drives.

I did run into a situation with my Mozy backups that should have been immediately obvious, but I did not catch it for a while.

The first backup you do with an offline service takes a good while.  I backup about 30G which is certainly not an exorbitant amount, and the first backup took 3 – 4 days elapsed time with the computer not running 24/7.

Each day the backups run anywhere from 40 minutes to an hour.  However, ever now and again the backups seemed to start over, and take  the entire 3 – 4 days again.  It happened again this week so I finally stopped to figure it out.

Every now and again I would start the computer without the external hard drive – which I do from time to time if all that I am going to do is use the Internet.  The problem happened when the automatic backups started during the time the external hard drive was off.  Mozy did the little bit of backups from drive C: and then assumed 29G was deleted, and deleted it from my backups.

The next backup had to start over.  Once I figured it out, it was easy enough to control, but it took me a couple minutes of thinking to figure out what was happening.

A quick email to Mozy support (which is very responsive) confirmed my diagnosis.

There was a turning point in the development of software when it was finally discovered that it took more time and money to maintain a system than to develop it.  The emphasis shifted to creating systems that were easy to maintain.

To make a system easier to maintain the first goal was to create a system with fewer bugs.

To create the system with fewer bugs, there were a number of processes that were used.  One of the most interesting and controversial was the “code walk through”.  Programmers after they created a piece of code, usually a subroutine, sat with their peers for a review of the code.

The goal was to reduce bugs and reduce overall maintenance.  Programmers are not known for their social tact, and it was difficult at first to teach that when you reviewed code, you had to do it with some tact.

Some programming sites made the rule that before you pointed out any errors, you had to say something positive.  There was a famous story that one programmer who after reviewing the code of another programmer struggled to find something postive to say, until he finally blurted out “thank you for writing so clearly so I can see all the errors”.

To deal with the issues of complexity and flexibility in software development, programmers and software developers have tried various techniques.

One technique is to try and make the software as flexible as possible.  It is hard to anticipate each and every requirement for the system, so the system is made as flexible as possible.

There are several methodologies.

• One is make the system is “data driven”.  There is a database or data source that determines the behavior of the system.  To change the system, the data is changed.  We see examples of this when we provide information to a system like Header, Title, etc. that are then used throughout the system.
• The other is to make the system code as easy to maintain as possible.  This has led to various techniques such as
  • Structured Programming
  • Object Programming
  • Reusable Code
  • Modular Programming

All these approaches are designed to make changing the system easier and quicker.