Artistic Threads

In a earlier post I wrote about how to monitor performance, but how do you plan for great throughput from the start? In the modern world of distributed services and multicore computers you can improve performance considerably by careful use of threading. Before jumping in and firing off threads for everything however, consider when they can actually be of most use.

First, if you fire off a larger number of threads than the cores on the client, multiple threads don't really gain you any advantage. Even with multiple threads started, the processor can only have a fixed number of processors "alive" at any given instant. You won't gain much from multiple threads on processes heavily dependent on SQL back ends either: the database engine already multithreads its queries. But other situations could be good candidates for threading.

If you need to repeatedly call external services for example, or are waiting for data back from remote servers, then using multiple threads can be a lifesaver.

Earlier I wrote more about what to stay alert for to keep your processes threadsafe, but regardless, a general guideline is to tightly manage the quantity of threads that you allow to execute simultaneously.

When you encounter an error in a thread's initiator you need to remember to safely bail out all of the threaded children from their initiator, something that I also discussed in this post. Threads can be tremendous performance enhancers if used carefully and artfully.

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.