The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How Google's design choices can make your system unusable

[Yes, this story really IS about software design.]

All of my time for seven days (and a substantial amount of the
time of several other people) was lost to dealing with a
completely unnecessary problem caused by Google Desktop Search.

What's worse, it wasn't apparent to us that GDS was to blame,
right up until the final day.  People with slightly less
persistence who experience this problem, may well end up
doing a complete system wipe/rollback in order to make their
systems usable again.

The problem appeared after restoring a system, from a backup
in the form of a file-by-file clone of the primary
Windows 2000 Pro partition. 

After the restore, it was possible to boot and even login to
the system, but the system was essentially unusable because
the Windows shell, specifically explorer.exe, refused to run. 
Upon login, the taskbar would briefly flash, and the desktop
showed none of the items contained in the Desktop folder. 

It was possible -- although excruciatingly tedious and
time-consuming -- to open a single files or applications at a
time, by using ctrl-alt-del to invoke Task Manager, then
File ==> Run ==> Browse to navigate the directory tree.  But
any attempt to invoke explorer -- e.g., by right clicking on a
folder in the Browse dialog and then selecting Open or
Explore -- would immediately fail, with no messages. 
Furthermore, opening anything immdiately killed Task Manager. 
Running mmc.exe to view the System Event logs revealed
nothing.  And shutting down the system would produce a BSOD,

We were stumped.

To make a long story short, omitting the recounting of the
6-day diagnosis process, here's how GDS caused this problem. 
GDS is distributed as 30+ files, many of which have long names
like GoogleDesktopAPI2 -- including .exe and .dll files. 
During the installation, the name of one or more of these
files is entered in the system registry, presumably as part of
what's needed to ensure that GDS can monitor file activity to
perform indexing. 

BUT, this registration process uses, *not* the long names
specified by Google, but rather the DOS-form ("8.3") names
which are associated with these files.  And, if these files
are restored from a backup, the short names aren't necessarily
preserved (depending on the exact method used to perform the
restore).  As a consequence, the name entered into the
registry may no longer exist in the GDS folder, or may even be
assigned to a different GDS file.


1. GDS installs some files in its folder which are named
aa ### WARNING - Do not
ab ### move or delete these
ac ### files - your system
ad ### may stop working

This is atrocious and irresponsible human-factors design.

-- a. For one thing, at what point does Google expect users to
notice this warning? How many users do you think, every time
they install any new software, will immediately inspect all of
the file-names which were installed?

-- b. Furthermore, the warning is ambiguous: perhaps the
reader will at least know that it's risky to move the folder
to another location. The most which Google can reasonably
assume of the reader, is that the reader will know that it's
risky to delete the files: the reader is even encouraged to
this milder and narrower interpretation by the remainder of
the warning, which says...
af ### To uninstall use
ag ### Add-Remove programs
ah ### in the control panel
ai ### or run
ak ### GoogleDesktopSearchSetup.exe -uninstall

-- c. Having read the warning, how many people do you think
will interpret the warning to mean that it's risky even to
*restore* the files (depending on the tools which are used)?

-- d. Among the people who do happen to see the warning, how
many will remember it months later while performing system
maintenance -- or while in the stressful and distracted
circumstances of peforming an emergency recovery?

2. This risk created by GDS was totally unnecessary and simply
avoided: all they had to do was to distribute the risky files
with Google-assigned 8.3 names, such as "gdsapi2.dll".
Apparently, some misguided (or simply arrogant?) developer (or
designer or product manager or marketing person) thought that
it's more important to use cosmetically attractive names such
as "GoogleDesktopAPI2.dll". As someone who has previously been
a developer for software vendors, I can confirm that even
decisions at such a picayune detailed level might be made by a
committee, frequently on the basis of standards layed out in
a document which dictates corporate standards for "branding".

3. I doubt that Google could even plead that this issue is a
matter of common practice among developers. On the system where we experienced the problem, the Program Files folder
contains well over 200 products and packages, from a wide
spectrum of sources ranging from sole-developer share-ware,
through open-source, all the way to the behemoth world-famous
vendors. I scanned the registry for other occurrences of
system-assigned 8.3 names, and found only five -- and none of
those involved functions whose failure could make a system

This next item might be of particular interest to anyone else
who supports an "enterprise" (i.e. corporate I.T.) environment.

4. Perhaps the worst kind of software deficiency is the kind
which you discover a long time (or never) after it has
silently affected you -- especially in circumstances which are
"mission-critical" or related to loss of business, or to loss
of productivity, or to human safety.

So ask yourself:
"Is this really the level of quality which I want to introduce
into the environment which I'm responsible for supporting?"
How many of your supported users (or the people who support
them) will lose time to problems like these, perhaps
needlessly performing complete rollbacks of their desktop systems?


5. To add insult to injury, GDS isn't even particularly

--a. GDS doesn't index the total content of its documents,
only the first <nnn> number of bytes.

--b. Furthermore, GDS doesn't even handle "OR" arguments,
which I just recently learned by chance, after months of
seeing puzzling scanty search results which I had been
attributing to faulty remembrance on my part.

In other words, if you want to search for stored desktop
items, or visited web pages, which are related to overheating
of your system, you can't search for "cool OR cools OR cooled
OR cooler OR cooling OR coolant OR heat OR heated"...etc.
You must instead perform numerous separate searches (and then,
of course, wasting your time during each separate search by
having to wade through all of the redundant hits which you
already encountered during the preceding single-word searches).

And if you're unaware of this limitation, and you're already
familiar with searching at, all you know is that
you're getting few results for the search (or none), not
knowing that *this* Google -- unlike -- is treating
your request as though you were searching for items which
contain ALL (not "any" of the search arguments.

Note what Google says at :

-- "... provides FULL text search ... creates an index of ALL
your searchable information ... you can search the FULL TEXT
of your email, files, viewed web pages ..."
(see item 5a. above).

-- "... search your personal items AS EASILY AS you search the
Internet using Google ... just do AN ORDINARY GOOGLE WEB
SEARCH ..." (see item 5b. above).

This amounts to deceptive practices.

development priorities are a business decision. But I do fault
Google for publicizing and distributing GDS with no mention of
these issues, so that users experience these limitations
silently and insidiously.

Despite Google's vaunted motto of "Don't be evil", their
behavior increasingly mimics that of other vendors who engage
in vapor-ware practices (such as premature releases or
premature announcements) in order to gain mind-share and
market-share over competitors.
K Nard Send private email
Friday, May 27, 2005
Unrelated to the GDS issues, this seems like a good time
to mention -- especially to potential customers of expensive
Google "enterprise" products -- that even the "real" Google
search engine produces anomalous results. Try the following
at, and then ask yourself, "Do I want to use this
same proprietary technology to run my business?".

--a. at the top of the search page, click
"Preferences" and set *both* of "Interface Language" and
"Search only for pages written in these language(s)" to English.

--b. search for: dontdisplaylastusername

--c. Go directly to the bottom of the last page of results,
and click "repeat the search with the omitted results

--d. Go directly to the last page of results, and note at the
top where Google tells you the exact number of results it
found. At the moment I'm writing this, that number is 743.

--e. In the search box, after 'dontdisplaylastusername',
*add* the following to the search argument:
In other words, you're asking Google to *narrow* your previous
results, to include *only* results which *also* contain one or
more of the additional words.
Now click Search.

--f. Repeat steps "c." & "d.".

With the modified (i.e., additionally restricted) search,
you would properly expect to get a count of results which is
equal or *less* than the previous number. But, at the moment
I'm writing this, that number is 764.

In other words, one or both of the searches produced
inconsistent results. Either the first search dropped some
matches, or the second search produced some bogus matches.

Now, this behavior might be acceptable (although incorrect)
when you're engaging in personal web searches, given the
fluidity of the entire set of web pages across the whole world.
But, if Google's purchasable enterprise products are using the
same core search-engine -- not an unreasonable conjecture --
then it's disturbing to think that there might be businesses
which are using that identical technology for important
data-mining applications.

p.s. -- I reported this bug to Google months ago. At the
beginning of April, they sent me a note which only said,
"We're aware of and investigating the problem." Almost two
months after their acknowledgement, the bug remains.
I'd hate to be one of the businesses which are paying Google
for placement of ads based on search results.
K Nard Send private email
Friday, May 27, 2005
For the Google search - if your second search is for "dontdisplayusername reason bug product alert", it gets 29 records and all of them seem to be relevant... how does "|" help? I guess it means "Or" but I thought Google didn't do "or" searches.
Saturday, May 28, 2005
I was just about to make a post on how Google Desktop Search was beta, when I went to their website and found that it isn't.

So, one more non-beta Google product. Interesting.

GMail should be coming out of beta pretty soon, I would think. I find it amusing that they still require invites, when getting invites is as easy as visiting

Google Groups has been in beta forever and I can see why. It royally sucks.
Ben Atkin Send private email
Sunday, May 29, 2005
I have seen other items which depend on the 8.3 mangling of long file names. That is VERY VERY poor design, as you say. Even adding a file to a directory might change the mangling.

Sunday, May 29, 2005
Not to defend Google (this sounds completely evil as well as retarded) but why the hell does Windows die if the google desktop search has a file moved/deleted/renamed ?

I think we can rule out conspiracy, which suggests that GDS is hooking into the OS (I would assume the shell, if it's not killing the entire system) in some manner or another that's fragile in the face of a deleted file.

That's stupidity and evil on the part of google revealing stupidity on the part of Microsoft.  :)

If Windows could detect the missing file(s) or notice that GDS had crashed and kill it, then it could pop up a useful dialog box that would still have revealed the Google developers as not being too smart while making someone at Microsoft look brilliant. If there's some reason why this simply can't be done, then the google developers are insanely evil for failing to (a) make betetr software and (b) provide a simple way to identify and repair the problem.

Oh, and despite the fact that google's search engine may not be omniscient and telepathic, the fact that people who don't understand search engine basics are criticising it disturbs me.  :)

Sunday, May 29, 2005
Google Desktop Search runs as a Windows service. It's entirely possible for a service to screw up Windows, in the same way that it's entirely possible for a daemon to screw up UNIX.
John Topley Send private email
Monday, May 30, 2005
> GMail should be coming out of beta pretty soon

I hope they fix their attachments handling before then.

Monday, May 30, 2005
John: If a *nix daemon fails to start you look in the logs and find out why. Ultimately, it's just a shell script that failed, oder? The system keeps going. I can't think of a single non-core daemon that would prevent the system from coming up if files were missing.

(caveat: I'm a programmer, not a sys-admin)
Richard Rodger Send private email
Monday, May 30, 2005
I thought the point to the Windows service system was (among other things) to isolate services: if one fails horribly, anything that relies on it won't work but the entire system won't die. If anything, the phrase "it runs as a Windows service" should mean that it can't do that much damage.

I can easily see something *inside the kernel* killing the system (kernel device drivers that crash are a serious problem), but again the kernel should still be designed to detect modules that can't load and cleanly detach them.

Just out of curiosity: can anyone confirm that Windows services are genuinely this destructive?  Or is there more to the problem than that?

And UNIX lets you run daemons as severly restricted users, which limits their ability to bring down a system.

But still, anyone who uses dummy files to stick "do not touch these files" comments into a directory should be shot.  :)

Monday, May 30, 2005
The original poster is very harsh when criticising the Google developers. Ultimately, this is a bug, nothing more, nothing less.

I've made design decisions that turned out to have negative consequences that I just couldn't see in advance. That's what has happened in this case with Google Desktop. It is a subtle bug that will occur infrequently, and therefore probably made it through testing.

I suggest reporting the bug to Google so they can deal with it. Maybe even send your suggestion of only using 8.3-style filenames for the registered DLLs
Travelling Steve Send private email
Tuesday, May 31, 2005
> can anyone confirm that Windows services are genuinely this destructive?

Windows services cannot do more harm than any software running with the same rights. They are in user mode and not in kernel mode, so they cannot drive Windows into BSOD without an OS bug.

Historically, Windows services are running in the user context of the LocalSystem account, which is extremely powerful. Any secure coding guides discourages that user context. Some services are marked as "interactive", which means that they can access to the current user's desktop (normally they run on a different window station), exposing a serious threat on the security of the whole system.

BTW I don't know if GDS installs any kernel mode drivers, but crashing the shell (explorer.exe) is not that difficult at all, maybe it is the most poorly written part of Windows.
Tuesday, May 31, 2005
I've not had good results with GDS for searching WEB HISTORY  (actual page contents of web pages visited). And that's the ONLY thing I use it for. (I use Copernic (free, much better) for searching local files).

Time to uninstall Google DTS perhaps.
Mr. Analogy {uISV Owner} Send private email
Tuesday, May 31, 2005

Check out the women with their thumbs up. They say to chill out, Google is hip and fun!

Sunday, June 05, 2005
I would like to see Google's response after you report this to them.
David Walker
Monday, June 06, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz