The most robust software project I ever worked on

by Michael S. Kaplan, published on 2005/03/03 09:40 -08:00, original URI: http://blogs.msdn.com/michkap/archive/2005/03/03/384392.aspx


I have been talking vaguely about this project a bunch of times, so I figured I would just post about it directly once and get it over with. There is even a cool international bug in there somewhere!

The project was the Partial Replica Wizard.

It was a originally a wizard for Access 97. Jet (version 3.5) has added partial replication as a feature and the Access folks (in their infinite wisdom) had decided to not support it. Jet replication in general was not a feature they ever did much for, as it proved to be a feature that sold a few boxes as a line item on a product marketing description but did not require much support otherwise. Why break the tradition for an extended feature that had taken them through the original? :-)

Now I had been doing consulting work using replication for customers since Access 95 during the beta, so I was of two minds:

I had even co-written an article with Lynn Caldwell (nee Shanklin) on how to "fake" partial replication with Access 95/Jet 3.0. So having the feature added in a robust way was pretty cool.

But they didn't want to touch it. One program manager told me that not enough people used the feature to justify making it easier to use, without even a trace of the irony that such a statement deserved. Make a feature hard to use and then refuse to fix the issue on the basis that no one uses it? Perhaps not as much chutzpah as killing your parents and then begging the court for mercy on the grounds that you are an orphan, but it is on the same order of magnitude!

So one night I had an idea. I started writing a wizard that would allow a user to create one partial replica filter (like all the customers in Ohio or all of the salespeople that sell power equipment or whatever) and would then walk all of the tables in the database and extend that filter based on the relationships. It seemed better as a core product feature than a wizard, but I figured it would make a cool proof of concept. Maybe it would appeal to people enough that they would pick up and start putting some resources into the functionality (and yes, I was as naive as this makes it sound like I was).

Now as the idea was very strightforward, the algorithm used to walk the relationships was also very straightforward. It used a "family" metaphor to explain itself (in my defense, the idea came to me very late at night). I'll see if I can recapture it here:

The rules for the partial replica are also very straightforward, and involved filtering the table so that related records or records would reasonably needed would be brought in. They could then choose in the case of "Total Strangers" whether to bring in all records or no records depending on their preference. A table could only be visited once and the properties would never be set on it again (we have nice, normal, G-rated families here!).

It then creates the replica, applies all of the rules, prompts for what to do with the "total strangers" (include all or include none), and then populates it with data. It even provides a report containing every property value it set so that you could do it all yourself programatically later on if you wanted to. It is completely re-entrant so that on demand you can change the center of the universe and will remove all the old rules and apply the new ones.

Of course there could have been more functionality (for an example, see what Phillip Garding did with SQL Server's filtered publication wizard -- 100% modelled after this wizard but allowing for example more than one main filter). But it was only intended to be a proof of concept -- I honestly expected them to produce something built into Microsoft Access 97 directly. I emphasized how easy it was to do, in order to help prove how easy the core feature would be.

The wizard was not something that Microsoft could claim to own (since I was just a contract resource and they had refused to do anything for the feature), but when they saw it the response was simple -- how much did I want for it so they could ship the wizard?

I have since been told several things by people both inside and outside of Microsoft:

  1. Everything that happened was completely predictable and the fact that I was surprised at the result was just me being naive.
  2. I should have built in the additional features I wanted to be done before I demonstrated it to anyone.
  3. I should have held out for more money (I gave it to them for my hourly rate)

They are all 100% correct.

But ignoring that I am forced to admit that (to date) this wizard had fewer bugs reported against it (by testers internal to Microsoft or customers external to it) than anything else I have written, despite heavy usage against complex databases. Other than some minor UI spec issues that were handled as bugs (it was obviously written without a spec, but some after the fact UI decisions were made by program managers!), there has really only been one major bug reported against it (more on that in a moment).

This one simple fact has driven my desire to keep design plans on all future projects as simple and clean as possible -- or, in the words of James Doohan (Mr. Scott), the more one overthinks the plumbing, the easier it is to stop up the drain. This is not always easy to do (preaching conservative plans and simplicity to people who work on a project the size of Windows often falls on deaf ears, despite the Star Trek III quote that agrees with the point!) but I have remained an advocate to this idea even to this very day. The implementation may end up being very complex, but the basic principles of the idea should remain simple and straightforward, with clearly reasoned principles.

So what, you may be asking, was that one major international bug that was in the wizard?

Well, the filters that one creates on tables are either

It felt kind of horky to me to hardcode the strings "True" or "False" into the code since I had Boolean VBA variable with the value to put in, so I used the CStr() VBA function to convert that Boolean variable into a string (people familiar with COM's VT_BOOLEAN may now know what the bug is!).

The bug came in when someone in the French subsidiary reported that the wizard did not work on a localized French Windows (this was prior to Windows 2000 and prior to a lot of the knowledge of internationalization issues I picked up since then).

The reason for this was that the French system was translating False to Faux when one called the CStr function on a VT_BOOLEAN. Don't even get me started on what a bad idea that is, but of course the Jet Engine doesn't do that, so it was causing the wizard to create filters that did not work properly.

Yuck.

Oh well, at least the fix was easy!

While I had done some internationalization work before, I can honestly say that it was this one bug (and the problems inherent in the way people used internationalization inappropriately) that fascinated me enough to make it the focus of most of my future work. Over half of my new contracts after that ended up being based on internationalization, globalization, and localizability issues.

Talk about turning a career on a dime!

And I owe it all to that one little Access wizard, the one that also changed the philosophal nature of my development efforts, too. Makes me wish I kept the source code for it, just for the memories? :-)

 

This post brought to you by "Ω" (U+03a9, a.k.a. GREEK CAPITAL LETTER OMEGA)


# Sriram on Thursday, March 03, 2005 11:17 AM:

Amazing story!

I've been bitten by this lots of times too. Trying to do something the 'clean' way (like your CStr call) and then realizing that the 'unclean' way is not that bad after all.

# Sriram on Thursday, March 03, 2005 11:25 AM:

Offtopic - Since the comments on the original post are closed, I'm posting here.

Thanks are in order - for reading one of your blog posts lead me to a possible bug in my code. See http://dotnetjunkies.com/WebLog/sriram/archive/2005/02/28/57647.aspx

# Michael Kaplan on Thursday, March 03, 2005 1:36 PM:

Glad you enjoyed, I have been thinking that a fun story from the past every now and again would be interesting here....

And also glad to help. :-) Hopefully you will notice that the suggested solution also has as bug in it, one that I am working to get into future service packs of Windows XP and Server 2003.

# Dean Harding on Thursday, March 03, 2005 2:43 PM:

HA! The analogy of the person pleading for mercy after killing his parents, on the grounds that he's an orphan, is classic! There's so many situations I can think to use that in :)

# ChrisO on Thursday, March 03, 2005 7:52 PM:

Since I am, comparatively speaking, a novice with software may I ask a question?

Exactly what is the definition of “Robust software”?

Robust hardware costs a pretty penny, should not “Robust software” cost the same?

Coming from a hardware background, even hardware can’t be relied on.

When required, hardware is triplicated and operates through a fail-safe mode and a median selector to try to ensure ‘System availability’. Robustness (reliability of the single item) and System availability (fault tolerance of the system as a whole) should not be confused.

To me it is simply a fact of cost, how far and how much we are prepared to pay.

Regards,
Chris.

# Michael Kaplan on Thursday, March 03, 2005 7:57 PM:

Well, the wizard was given away free via a download for access 97, and although there was a price on the later versions of Access and Office I sincerely doubt that they changed the price of either due to the wizard being there.

So if the definition of robust is related to cost, then I guess you would not say it was very robust.


But dictionary.com says that robust can mean "Powerfully built; sturdy" and that is what I am talking about -- virtually bug free, does the job both reliably and well. Seems pretty robust to me....

# ChrisO on Thursday, March 03, 2005 8:27 PM:

G’day Michael.

[quote]
“So if the definition of robust is related to cost, then I guess you would not say it was very robust.“[/quote]
That was exactly my point, robustness (single unit failure) and system availability is related to cost and the comparatively cheap cost of the Microsoft product seems to prove the point.

Notwithstanding the attempt to do so, could anyone afford ‘Bullet proof software’?

Not me, and you and Microsoft should be appalled for keeping the cost down.
(It seems very few people think about the cost of the software they are using.)

Regards,
Chris.

# Michael Kaplan on Thursday, March 03, 2005 8:36 PM:

Hmmmm.... I am not sure that raising the price is the right answer. And I do not base how solid the code that I write is on the basis of whether they pay me more.

I guess I just do not see money as the inducement here. If people like the software. they should buy it and enjoy it. My own contributions are minor but I know that even they are an important part of that, often to people who never realize anything special was done (internationlization is usually only notice when it done wrong).

If I were in it for the money myself, I'd still be consulting. But I'd rather be where it is all happening -- and right now that is here. :-)

# ChrisO on Thursday, March 03, 2005 8:40 PM:

It happens…

Appalled…???

How about applauded. (Need a new spell checker.)

# Michael Kaplan on Thursday, March 03, 2005 8:51 PM:

Ok, that makes a little more sense. :-)

# Dean Harding on Thursday, March 03, 2005 9:12 PM:

The difference between hardware and software is that the cost of actually producing the hardware is a significant proportion of what the consumer pays. That is, if you're make a redundent system, you're essentially giving the consumer two totally independent components, when one works just as well - thus doubling the cost to produce the piece of hardware. Also, higher quality component require higher quality base ingredients (thus more expensive, for example gold is more conductive than copper, but gold is also much more expensive), as well as a more controlled manufactoring process (cleaner environment requires expensive dust extractors, and so on).

Software, on the hand, is more research than engineering. Once you've built the software, it costs next to nothing to duplicate it a thousand times and ship it to consumers. So if you pay $200,000 to develop a piece of software, but you only sell it to 10 people, you need to charge them $20,000 each to break even. But if you spend $20,000,000 to develop software, and sell it to 1,000,000 people, you only need to charge them $20 to break even.

That's why Microsoft can deliver high-quality software for cheaper. Even though they spend a hell of a let on R&D, they sell a *lot* of copies of the final product, so each unit only needs to sell for a small amount to make a profit.

# ChrisO on Thursday, March 03, 2005 10:25 PM:

Dean… we do not actually disagree?

There is no difference between a software and a hardware solution in a ‘high system availability’ situation.

Each is interdependent on the other and each dependency brings with it its own failures.

Hardware normally requires the release of stored energy in a spring, and even that is not secure enough under certain circumstances. (Yet it goes very close to the truth.)

If we wish to look at security, in all manifestations of that sense, then we need to look at the cost of doing so and not just the immediate sense of doing so.

Regards,
Chris.

referenced by

2015/08/27 Trying to build some kind of a narrative #6: Several of the more intriguing of the other 32 (of 37) contracts at Microsoft

2008/09/16 Vérité (add MUI support in a service pack) ou oser (tell me whether returning 'vrai' was intentional)?

2007/10/13 Not exactly a career

2007/07/18 That's a lot of freaking downloads, mister!

2005/06/06 'desire to deeply understand core globalization features at their lowest levels'

go to newer or older post, or back to index or month or day