When I say “backwards compatibility”, I’m thinking of:

 

(Is that the generally accepted definition of backwards compatibility? I should look, I guess.)

 

A tertiary goal of mine for backwards compatibility is to make that support (and proper display) of old data as invisible to the user as possible. In other words, the new version “just works” with the old data. No complicated upgrade processes.

 

Those have been my goals with every new version of The Journal since 1996. I’ve been mostly successful at it, if I do  say so myself, with only a few hiccups along the way. And I’d like to think I’m getting better at it.

 

I get irked when the developers of software I use don’t seem to have the same priorities. (Just like I tend to get pissed off when the customer support I receive isn’t up to my own standards.)

 

Yes, supporting old data is a pain in the ass.

 

Tough.

 

As an aside: What I find kind of funny is that since EXE sizes no longer have much of an impact on users, each new version can effectively include the old version in its entirety. (I think Windows does this.)

 

The Journal v1’s EXE was about 750K. Each major update has, so far, doubled the EXE of the previous version. I trim everything I can, of course, but I’d rather have a few extra MB’s of EXE than “cut off” a user. (I’m pretty sure, though, that GUI code and database code and similar library code make up the bulk of the EXE. Which is to say: It ain’t my code swelling things up. )

 

Anyway, I know some “programmer putzes purists” and “design morons purists” think of backwards compatibility as the Root of All Evil. They want each new version to totally replace the previous versions–wiping out the mistakes and missteps that plagued those previous versions–all of which are gone now, of course, totally fixed in the new version. They are stupid idealists and only want to look forward. Not backward. They believe that sissy users should suck it up and upgrade and fix all their own mistakes–even those mistakes made in good faith, properly using the old software.

 

There is only One True Way to these idiots dreamers–and it doesn’t include backwards compatibility.

 

Yeah, those people bug me. Can you tell?

 

In summary: Backwards Compatibility == Good Thing.

 

-David

 

The first implementation phase of Project Vee was getting the original application to compile in a sparkling new development environment. That took a week or so (because being 6 years behind in your dev tools is a long time to be behind).

 

In the second implementation phase I replaced the database backend. And wrote the routines for properly upgrading data from earlier versions. And, while I was at it, totally redesigned how the internal data structures communicated with the database. All of that took a couple months (because when you change the database, you change the backup/restore process and all maintenance functions, the new installation detection and similar very low-level functionality).

 

Now, in the current implementation phase (which is called IP2, because I’m a geek), I’m re-designing Project Vee from the inside out. Which is to say, I’m streamlining (and/or replacing) certain core data structures in anticipation of extending those streamlined (and/or replaced) core data structures in anticipation of totally overhauling the UI.

 

I start by describing (in The Journal, of course) where I want to end up. Then I figure out which existing data structures  need to be changed or extended to get me there. And then I make small, isolated change after small, isolated change, doing full builds and testing against legacy data as I go, because I don’t want to lose anything on the way.

 

Because backwards compatibility must be maintained. (Anyone who tells you differently is an idiot. But that’s another topic.)

 

And so the summer grinds along.

 

-David

 

What I need is an intern. [*] Which is to say: “Someone I can dump this really shitty grind of a task on.”

 

Gawd. What the hell was I thinking?

 

Tedium following tedium. First, reviewing a quarter-million lines of code to convert the project to Unicode. And now, going through the same damn quarter-million lines of code again to separate out the UI display text for localization (and–maybe fortunately–finding a few missed parts of the Unicode conversion).

 

12 years of “mostly adequate” coding practices coming home to roost. At least Delphi 2007 has automated some of the really tedious parts. But I still have to review and approve. And the RSI’s are beginning to loom.

 

Even better: after I’m finished with the current bullet point … the hard work begins.

 

Back to the grind…

 

-David

 

[*] No, not really. If you’re cute and female, my wife will exercise her veto. If you’re neither-nor … well … the pay is total crap (AKA, “nothing”). And I can be very demanding for a guy paying total crap.

 

I’m in the process of converting a 12-year-old code base to Unicode (Windows UCS2). That’s one of the strategic goals of Project Vee.

 

Oh, the joy of it all.

 

Delphi makes it pretty easy. For the most part, WideStrings are handled the same as what are now called AnsiStrings. My chief gripes/concerns are:

 

I cringe at the thought of the nifty new, hard-to-find bugs that I’m introducing to a stable product.

 

Still, I look forward to how much this could/will broaden the scope of the final project.

 

And it’s good practice for the next strategic goal of Project Vee that will probably cause lingering headaches: localization.

 

-David