What we get “paid for” is actually dealing with a lot of crap code, some written by us, the rest written by others. Ayende has a great quote, broken English and all:

There are always at least two people in any software project:

• The developer who wrote the code.

• The developer who read the code.

They are never the same person, even if just by temporal dissonance.

In other words, we will generally have a thought of “who wrote this crap”, and most of the time, it is our past self.

As tempting as it is, we cannot simply try to create new projects whenever we encounter difficulties or better ways of doing things. We would never get things done.

There are however instances that demand a new project. Here are a few that come to mind:

• Platform is not actively supported or vendor’s development has reached a sunset.
• Another major technology has supplanted the one your using in the marketplace, one that would reduce your codebase significantly.
• You have to re-read nearly the entire codebase to make any changes or you have limited tests, specs, documentation, etc. on a key application. This is a special case, one that’s not very popular and easily ignored when we get busy, but in this event, you want to capture as much of the knowledge from the developers now, this is your “project”.
• Your application is small (e.g. 1 developer, handful of function points), these are the perfect environments for learning new technologies, techniques, etc.

Any others come to mind? Let’s have them!

If everything goes as planned, it’s trivial. For ActiveX DLLs, you can just use regsvr32 with the /u switch, like so:

regsvr32 /u dllFile.dll

For ActiveX executables, you use the /unregserver argument for EXE itself, like so:

ActiveXFile.exe /unregserver

Each ActiveX file has a class ID (CLSID) that uniquely identifies that file in the registry. When you unregister the ActiveX library with one the previous commands, all references to the library are removed from the registry. This is important if you’d like to update an ActiveX library that has had it’s CLSID changed. Normally, you’d just unregister the old library (using the old file), remove the old file, then copy in the new file and register it.

Lil’ Orphan Annie

So what happens if the old library file has been deleted? You’re stuck with all those old keys in the registry, and often times that will prevent the new from registering properly!

It just so happens I was working with a company that had a problem like this. Their product had several ActiveX exes and DLLS, and more often than not, when trying to update a client’s files, someone would forget to unregister the old libraries before removing them, so we found ourselves stuck in this mess quite often.

To figure out how to fix this, I decided to figure out exactly what happened when an ActiveX library is registered, so I could undo the changes. I did some research and concluded that when an ActiveX library is registered, the only thing on the system that changes is that several keys are added to the registry. There are several programs (mostly for installers) that will help you discover exactly how an installation has affected your system, but I wanted to try a free way. This is where a simple but irreplaceable tool came into play: the diff tool.

Visual diff tools rock!

Diff tools compare two text-based files (or blocks of text) and visually show you how those files are different. It’s an absolute must-have for programmers…when combined with a revision control software product like SVN, git, or Source Save, you can easily compare how a text file has changed since it was last ‘checked-in’. There are plenty of good ones out there…I’d recommend checking out WinMerge. It’s fast, free, looks good, and integrates nicely with TortoiseSVN.

So how is WinMerge going to help us here? Well, fortunately the Windows Registry Editor (regedit) provides an option to export the entire registry into a text file! So, discovering how your registry has changed after an operation is as simple as:

1. Taking a snapshot of your registry (export to text file)
2. Applying the change (registering your ActiveX DLL)
3. Taking another snapshot of your registry (export to different text file)
4. Comparing the two text files to spot the differences (Use WinMerge or other diff tool)

On to the next adventure

It’s ridiculously simple, but it works great, and it’s free. You’ll learn a lot about how much your registry is being used constantly by the OS and your running programs.

Now that we know which registry entries have changed, we can look for patterns and figure how to remove all traces of an ActiveX library from the registry just by knowing it’s original path. I’ll cover that topic in a future post.

I hope this can help out some poor soul still using VB6 ActiveX libraries!

How Did We Fall

Our applications usually start from a simple problem (something is costing someone money), but finish as masterpieces of problem solving. There are many natural complicating factors that go into this finished solution, the principal among them being users require various ways of getting the answers they’re looking for. Additionally, as a programmer, I rarely want to work on a problem that isn’t difficult. All of these forces contribute to taking a once simple solution and creating a Pit of Flexibility.

The Cost of Flexibility

Martin Fowler had this comment about flexibility in software:

The cost of flexibility is complexity. Every time you put extra stuff into your code to make it more flexible, you are usually adding more complexity.

This complexity will directly affect your users… which in turn will load down your support staff. You may have the brightest support staff, but problem solving a batch calculation system is a difficult and long business even for a few elements. Once the support staff is spent, inquiries will be sitting on the your door as the developer.

Often these problems aren’t bugs, they’re just buried complexity. Each element on even simple calculations can product a BigO effect on the final complexity of the answer. On applications written by different developers or teams, this problem solving can be compounded even further, taking the style and approach of each developer into account. So how do we as programmers shift these efforts back where they belong, so we can catchup on the latest 360 FPS find something more productive to do?

Jumping off the Treadmill

The way off this treadmill is simple: let the people upstream see what your application does, let them be able to analyze how your application solves the problem. Consider Wikipedia’s entry on problem solving, specifically the characteristics of difficult problems:

• Intransparency (lack of clarity of the situation)
  • commencement opacity
  • continuation opacity
• Polytely (multiple goals)
  • inexpressiveness
  • opposition
  • transience
• Complexity (large numbers of items, interrelations, and decisions)
  • enumerability
  • connectivity (hierarchy relation, communication relation, allocation relation)
  • heterogeneity
• Dynamics (time considerations)
  • temporal constraints
  • temporal sensitivity
  • phase effects
  • dynamic unpredictability

The next time my application is stuck in the Pit of Flexibility, and I cannot reduce its flexibility, I’ll be building time into my estimates for additional interfaces that provide:

• Transparency: context of the solution and problem
• Singularity: ability to find a specific example of a problem or work backwards from a solution
• Simplicity: capability to filter elements of a solution, while offering the completeness of the full answer