The Art in Foresight

In all my years of software development, I've never done anything the same way twice. Not because I didn't want to, but rather just because it was inappropriate. When you are starting a project you encounter not only a cascade of requirements and personalities, but also an onslaught of new technologies. You will therefore need to perform a balancing act incorporating a good bit of intuition.

One of the challenges of full-metal analysis is that three conflicting methodologies all need to be both performed and resolved. A sociological analysis considers the impact of the new design upon people and business processes. An object oriented analysis considers how to design abstract objects to adequately represent the business methods and data properties in a manner that will remain flexible. And a strategic analysis considers the appropriate strategic path of the company, path of the IT department, and ROI for the project.

Then beyond the analytical design, what languages, methodologies, and technologies are suitable to the task? What languages and technologies have industry momentum? Then using your foresight, what language and methodology will you wish you had chosen four years from now? Earlier I discussed in greater detail artful Vendor Selection; you need to recognize that developing a strategy to evaluate hardware and software vendors is every bit a piece of system development as writing the code.

When an executive looks into your eyes to see what you will do for the company, you either telegraph your future or you don't. Many times the only way to successfully develop a software product is to link to yourself in the future and ask for guidance for what you should do in the present. Foresight is the most important trait of a Systems Analyst or Software Architect.

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.