The Art of the Save

I suppose no matter how much somebody tells you, regardless of their advice, until you have the unfortunate happenstance yourself you're not going to learn except by experience. I'll share the story anyway... ignore it at your own peril. The advice is simple: save your source code in three places. Yes, three. Why?

A long time ago at a faraway company I had the pleasure of developing a state-of-the-art docketing system for a corporate legal department. I did all of my development off the C drive, and then after making any major change I would pull out my 5 1/4 inch disk labeled "Legal System Backup" and copy the source code over to it.

Well the inevitable happened: I had a hard disk crash. No problem, right? At least I have a backup. But after swapping in a spanking new hard drive -- holy O'Reilly: I can't read the floppy disk. Naturally about a week later a clerk in Legal wanted to add a new feature to the system. I could only shrug. I'm so sorry: we lost the source code.

Make three copies: save one or your disk, one on the network, and one in your off-site email box. Because there's no excuse for losing the source code.

Most modern developers work in an environment with built-in source code control, such as TFS or CVS. Occasionally though I've known companies that view their SQL views and stored Procs as something less than legitimate source code. Perhaps they feel a database backup is adequate coverage for the intellectual property.

Your source code (and SQL stuff) however provides an additional benefit to your employer besides being the cogs and gears that make everything work. Its /history/ is valuable for researching bugs. So make sure you not only keep three versions of everything that is currently running, but also keep all of the prior executed versions as well.

Artful Notes

It’s difficult to be a successful developer unless you keep prodigious notes. Notekeeping can be an art all its own: it’s really counterproductive at the point of code development if you find yourself with a huge pile of disorganized Post-Its of the use-cases.

While you are in the midst of designing software the useful information pours in across scenarios with a wide variety of formats. You may hold a meeting where everyone is talking. You may receive a PDF specification from a vendor. You may pick up the phone and chat with a colleague to answer some questions. You may shoot off an email that causes a cascade of responses. You may read something relevant on the internet at home. How can you possibly keep track of all this information in a sensible fashion?

Many of my developer friends like to keep spiral notebooks, but I’ve never been able to easily find what I’ve written previously. I prefer a mixed approach. I use a PIM (personal information manager) to gather and automatically categorize short sentence snippets of concise information. I keep folders organized on the network for documents. I also keep hardcopy in manila folders for documents that I think will have lasting importance. I keep a folder in Outlook for each gigantic-scale project. And I use Google Desktop to find my way amidst all of the detritus.

In meetings I take a single loose leaf of paper and then either transfer my notes afterward to my PIM or a more formal document to mail or file on the network. When I'm not at work I also *always* carry a Kindle for any spur-of-the-moment revelations.

Notekeeping is complicated: experiment with different methods and software to find something that works efficiently and correctly for your own style.

Artful Modality

In the many years that I've done software development I've noticed that systems written in-house tend toward two extremes. On one side you have useful software designed for a small quantity of people to do a very specific task, and on the other side you have somewhat clumsy software designed for two thirds of the company to support a wide variety of operations.

The smaller, task-specific software has tens and hundreds of flavors, yet it only survives three or four years until it gets replaced by a new incarnation. The multipurpose clunky software has just one flavor but seems to live for fifteen years, usually well beyond its prime. How come there is no middle ground?

Well just like in animation, sociology creates an "uncanny valley" of in-house software that doesn't comfortably exist. And this is due very much to the nature of people and the work that they do. In most jobs people tend to leverage certain knowledge and skills to support the company with specific tasks. A capable software designer can create very nifty systems that can maintain incredible complexity with the understanding that a moderately competent user will be trained on its use.

Such systems can be local successes even though they don't translate well to other users. And they don't survive for long because they don't incorporate the dynamics of both system-level and human-level changes. People change jobs and don't communicate all of the knowledge. Small systems fall into disuse because they are people and knowledge specific. They are still good for what they are good at: improving local productivity.

Large systems live past their prime for similar sociological reasons. The rate of change in people-skills overwhelms the complexity of linking processes. Linked processes become unlinked, and the training materials don't keep up with the changes in the software.

Large systems still serve a useful purpose however, to the extent that they organize people to work together. Where does the personality of a corporation really exist? In between the modes of small and large software.