Windows Registry Nightmares

I remember Windows (and DOS) before it had a registry... Do you remember? Remember the the Win.ini and the System.ini files (and Autoexec.bat and Config.sys)? Seems like a lifetime ago - and for some of you I guess it is...

At the time, configuring Windows sure was simpler. Simpler and easier. Simpler and easier and LESS RISKY.

Not so anymore... Today, the venerable INI files have been (mostly) replaced by the Windows Registry.

Have you tried editing the Windows registry manually. Go ahead. On Windows XP or Vista, try to uninstall an application - or better yet, a Windows installed service - manually. I dare you!

What's that you say? I must be crazy? That's insane? No one is dumb enough to try that? Well, I tend to agree with you. I consider myself a fairly experienced PC/Windows guy, but even I think twice before using REGEDIT.

But I do use REGEDIT.
Why? Because I have to.
Why? Because lots of software uninstalls poorly...
And I'm fed up with it!

This behavior reminds me of the bad 'ole days of "DLL hell". Anybody remember that? Where a software would install a DLL with the same name as a system DLL, or worse, it would install a system DLL that was the wrong version? Inevitably, it would screw up your system (in weird ways) and was masterfully difficult to troubleshoot.

And no, "DLL hell" hasn't gone away, but it's gotten better - or at least now it has to share the infamy with "Windows registry purgatory" (Wrp).
(Made that up myself... you think it'll catch on?)

For those of you who have not experienced Wrp (pronouced 'warp'), let me shed some light on this phenomenon. But first, read this to see what the Windows registry is so I don't have to spend a week relating my limited knowledge of the Windows registry.

In the Wikipedia article, near the bottom, there's a somewhat inconspicuous bulleted list item under the heading Advantages and disadvantages:

• "Any application that does not uninstall properly, or does not have an uninstaller, can leave entries in the registry. Over time the computer suffers "Software Rot" as the registry fills with left-over and possibly malfunctioning entries."

This is the nasty bugger... This is the root of my pain.

Why doesn't software written for the Windows platform clean up after itself well? Is it really that hard?

Ok, yes, it is kinda hard - especially if you register COM controls and/or Windows services. But, that should be part of the price of selling software on the Windows platform in my opinion.

This is the kind of software engineering I alluded to when I wrote about "Leaf Blower Coders". Face it,

the job is not done until all can be undone.

So, why is this a pain? I mean, really... all that's happening here is that there are orphaned registry entries that can't *do* anything and while it may bloat the registry, it's just a nuisance, right?

WRONG! Very WRONG!

As consultants, integrators, and custom solution providers, it is often common for clients to ask us to install software for them - usually on DEV or QA platforms. We act as experts and the client watches and learns as we show them how their software is loaded and configured. It's also not uncommon for us to be asked to *re-install* software that has been installed incorrectly, or we ask the client to *re-install* software themselves to insure that they have learned how to do it correctly. And THAT is when the uninstall becomes oh-so important.

It's in these *re-install* moments that orphaned registry entries can wreak havoc, I mean REALLY BAD BAD juju, on your day. I won't bore you too much more with details because I've rambled enough already, but orphaned registry entries (and really, *any* orphaned stuff) left hanging around after an official uninstall will cause untold problems with re-installing software - nearly always ending up with a failed install (or worse, an install that appears to work, but you don't find out it really doesn't work until much later after you've spent too much time trying to figure out why the software seems buggy).

So, here's my newest plea to Microsoft platform software vendors...

Please, please read the whys & wherefores of the Windows registry design and use - here, here, and here are good places to start. Take the time to map out all the registry entries your software makes when it installs and over the lifetime your software is installed (as well as any other configuration changes your software makes to the system as a whole). Document that in your software documentation. And then create a stand-alone uninstaller that reliably, repeatably removes them. We, your users and partners, need help to keep the Windows registry beautiful and tidy for future generations. Thank you.

Java Coding Guidelines - Part I

Does your company have a standard or set of coding style guidelines for writing Java code? Have you ever tried to write one?!?

From past experience, I'd recommend against it. Instead, I'd point you and your Java developers / programmers to Sun's Code Conventions for the Java Programming Language. This guideline has been vetted over many years and the entire JDK mostly follows it. As a result, most Java programmers are familiar with them, and Java code that follows these guidelines is generally readable by all Java programmers.

That being said, I'm going to ignore my own advice and begin writing a Java Coding Guideline for Xpediant. "Why?" you ask...

Well, I believe that Sun's guidelines are good, but incomplete. Remember, Sun's audience was much larger than Xpediant's audience, and therefore, had to be agreed to by a much more diverse group. Being smaller in size, we have the luxury of espousing and enforcing more specific coding practices - hopefully enhancing the quality, consistency, and effectiveness of our services.

So, where should I start? How does one go about crafting such a document?

Well, I believe the first thing that needs to be done is to create a vision - the same thing I would do for any new project.

Yikes.

Hm... Well, we are an integration and consulting company that works with and customizes software products that are Java-based, so it stands to reason that our Java code should be integratable with those products. And our projects generally deploy into enterprise-level production systems so the code should be high quality, production-ready. And since it's very likely we'll eventually turn over the code to the client to support, our code needs to be supportable and maintainable by other programmers.

So, the vision is:

To write a set of Java Coding Guidelines that:

• Enhances Xpediant's ability to write, test, deploy, maintain, and reuse its Java codebase.
• Consistently and seemlessly integrates with the Java codebase of the software products Xpediant's vendor partners create and sell.
• Consistently and seemlessly integrates with Xpediant's clients' existing and new Java codebase.

Next, I'll explore the most basic Java guidelines - get the easy stuff out of the way first!

Leaf Blowers

Have you ever seen those guys who cut grass that use a leaf blower?

As I was taking my usual walk the other day, one of them was blowing leaves and grass clippings across the sidewalk into someone's flowerbed - out of sight, out of mind.

That kind of behavior really gets to me. And it's not just landscapers that exhibit this lack of judgment.

I am seeing this kind of behavior with software engineering and application development professionals - especially as the complexity of coding increases.

Here's what I mean.

Software code can be generally thought of as either internal or external with respect to other aspects of a system, specifically if your company is a software vendor. The external code is the code that the source is available and the internal code is the code that the source is private.

What I've noticed is that internal code, if you decompile it, oftentimes looks like the flowerbed where the leaves and grass clippings were blown. It seems that some software engineering professionals allow their code to get cluttered with bad or ill-designed code that has been swept under the mat of abstraction and encapsulation (to use object oriented terms), and left there - out of sight, out of mind.

I urge software professionals and vendors to clean house. Your code needs some spring cleaning. Dust out the cobwebs and sweep under the mats. And then, put in place some best practices (continuous integration with unit tests would be a good start) that will help keep the leaves out of your flowerbed.

Just promise me one thing... Don't be a leaf blower.