We’re accepting applications for summer internships (2006) at Fog Creek. The deadline is February 2006.

Microsoft Jet

I’m glad Microsoft is upgrading the Jet engine once again. Even though they tried to tell application developers that we needed to move to MSDE/Sql Server Express, we know that our customers want their data in a single file and don’t want to have to install and administer SQL Server just to get to that file.

In the minus column, Erik Rucker seems to be saying that the new Jet engine won’t be redistributable. “Developers can still program against the Access engine, but since it isn’t part of the system any more, application users will need Access on their machines.” Great. That makes it nearly useless to typical ISVs developing Windows apps, so I guess we’re stuck with the creaky old Jet 4.0.

I haven’t heard the whole story yet, but Erik also says that the main big new Jet feature is this clever way of doing many-to-many relations between tables that was done solely to benefit SharePoint. That’s nice, hon’, but it doesn’t seem like such a big deal. I’m hoping Erik has a Jobsian “just one more thing” up his sleeve.

What I’d much rather see is real, authentic, fast full-text search. Access (Jet) 4.0 just doesn’t have full-text search at all, and it will be pretty darn disappointing if Access 12 doesn’t have a good, instant full-text search feature that’s native and built in to the engine at the deepest levels.

When we work on FogBugz, whether with Access (Jet), SQL Server, or MySQL as the backend, we spend way too much time trying to get full-text search to work even moderately well. SQL Server 2000, even though it technically has a full-text search feature, actually has a very-badly grafted-on full-text engine that is poorly integrated, slow, unreliable, and assumes that programmers have nothing better to do than think about when the indexes are built and where they are stored. In production, the full text engine grafted onto SQL Server 2000 falls down all the time. In particular, if you use a lot of databases and frequently detach and re-attach them (what we were told we have to do in order to use SQL Server as a “file oriented” database like Jet), the full text search indexes get all screwed up. They rely on insanely complex chunks of registry data to associate indices, stored in files, with databases. It is almost monumentally difficult to backup and restore full text indexes.

The fact that it’s 2005 and I can’t buy a relational database from Microsoft that has full text search integrated natively and completely, and that works just as well as “LIKE” clauses, is really kind of depressing.

A very senior Microsoft developer who moved to Google told me that Google works and thinks at a higher level of abstraction than Microsoft. “Google uses Bayesian filtering the way Microsoft uses the if statement,” he said. That’s true. Google also uses full-text-search-of-the-entire-Internet the way Microsoft uses little tables that list what error IDs correspond to which help text. Look at how Google does spell checking: it’s not based on dictionaries; it’s based on word usage statistics of the entire Internet, which is why Google knows how to correct my name, misspelled, and Microsoft Word doesn’t.

If Microsoft doesn’t shed this habit of “thinking in if statements” they’re only going to fall further behind.

About the author.

In 2000 I co-founded Fog Creek Software, where we created lots of cool things like the FogBugz bug tracker, Trello, and Glitch. I also worked with Jeff Atwood to create Stack Overflow and served as CEO of Stack Overflow from 2010-2019. Today I serve as the chairman of the board for Stack Overflow, Glitch, and HASH.