Failure

Lately my friend has been noticing that the editor in NetBeans occasionally refuses to save his edits. He can hit save all he wants, but until he restarts the IDE, the files on the disk are not being updated.

Yesterday, I did a bit of work in NetBeans using the jVi plugin, but this morning I noticed that my edits were gone. I likely saved many times as I often hit :w just because way back in the early days we couldn’t trust that a machine would stay up for very long, and that old habit of constantly saving became automatic. I can’t remember if I compiled the changes or not.

I worked for just over an hour and wrote several new methods. Hours later, I shutdown the machine. The version of NetBeans I’m using at home on my Linux box is 6.8, and my friend is using 6.9 on Windows.

I’m not entirely sure of what is happening, since in my case the editor is a vi-like plugin, and in my friends it is the default editor. Our versions are different as well. Perhaps in my efforts, I forgot to ever save (which would be highly unusual for me), but certainly during shutdown there were no dialogs or messages that I saw. It was a normal shutdown. Certainly for my friend, he clearly demonstrated that the ‘Save’ button was being pressed (multiple times), yet the file was not being updated.

Mostly likely it is some sort of threading problem. These seem to be the bug du jour, replacing the ever irritating ‘loose pointer’ in C. Threading is far easier to write then it is to understand, and problems with it are easily missed (or ignored) in light-weight testing. Thus we are inundated with simple race conditions that cause infrequent problems.

What I am sure of, is that if there is anything you really want and need from an IDE, it is the ability to save your work and know that it is saved.  

Way back in the early days, when things were a little more chaotic, it wasn’t unusual to work for a while, forget to hit save and lose a lot of effort. Gradually, over the years this situation was fixed in a number of different ways. Microsoft Word can make frequent backups, some programs like Google Docs save every few minutes. And of course we have source code control, so it would be easy to have a bunch of revisions stored automatically, allowing a user to move seamlessly between them in the advent of a problem, or even tap a need for a longer reaching undo.

Basically this is a solved problem. Collectively we have many ways of insuring that once entered, none of our work is ever lost, and we could even have the option of moving forward and backwards through it to undo or redo any operation made over a very long period.

This is one of the key benefits to using a computer. We can automate our efforts, and allow that automation to be tracked, examined and replayed as necessary. Computers are great at remembering things.

It doesn’t really matter how many fancy cool features a piece of software provides if it can’t do the basics. For an editor or IDE, it doesn’t get any simpler than being able to reliably save a file. Nothing is more irritating in software than to have a program lose your work, when we all know that that doesn’t have to happen.

In the end, software is only usable if you can trust it. And when that trust is broken you have no choice but to conclude that the software is badly written. There is absolutely no acceptable reason in the 21st century for a major tool like an IDE to still be suffering from a simple problem that was solved (and removed) decades ago.

But I guess everything old is new again, and so a few programmers have graciously allowed us to revisit old demons that should have stayed hidden in the past. Perhaps my excessive saving habit will come in really useful again.