david sidlinger

Merlin Mann, of 43 Folders fame, recently gave a talk at Google about Inbox Zero. Dealing with the deluge of email, personal and professional, is a topic near and dear to my heart. It’s nice to see a company that’s taking an interest in helping their employees with this. A video of the talk is embedded below. If you want the slides, you can grab them here [PDF].

Via 43 Folders

Over the years, I have been treated to a wide range of what I can only call perversions of technology. By far, the funniest I have seen is the Numbers Table. Why would you need a table of numbers, you ask? Because you need to count, of course.

The team of “developers” that came up with the Numbers table had heard that making a database call has overhead. Apparently, they had not heard about M.A. Jackson’s Rules of Optimization:

1. Don’t do it.
2. (for experts only) Don’t do it yet.

The system in question used pessimistic locking, another great story. There was a method to release multiple locks, which were stored in a database table. There was no way this performance critical code was going to call the LockRelease procedure for every lock. That would be insane! Presented here is the code that used the Numbers table. It’s reconstructed from memory, because I am too lazy to go digging through source control history. I have expanded a SQL function into the procedure definition and left out the irrelevant code.

First, the C# code:

public void ReleaseMultipleLocks(params Lock[] locks)
{
    StringBuilder builder = new StringBuilder();
    foreach(Lock lock in locks)
    {
        builder.Append(lock.LockId.ToString().PadLeft(11, "0"));
    }
    // Code to call the stored procedure with the (potentially) gigantic string
}

Now, the SQL:

CREATE PROCEDURE dbo.ReleaseMultipleLocks
(
    @LockIds nvarchar(4000)
)
AS

DECLARE @locks TABLE
(
    LockId bigint NOT NULL
)

INSERT
    @locks
SELECT
    CAST(SUBSTR(@LockIds, (11 * (Numbers.Number - 1)) + 1, 11) AS bigint)
FROM
    dbo.Numbers
WHERE
    Numbers.Number <= (LEN(@LockIds) / 11)
ORDER BY
    Numbers.Number

-- Use the @locks table to update the release datetime on
-- the specified lock records.  If I remember correctly, it 
-- used a cursor.

Wow.

So, in order to avoid those “expensive” database calls, we: build a string out of all those pretty, compact integers, pass that big string on the wire to the database server, create a table that holds (wait for it) integers, and use a huge table of numbers to do string parsing in SQL. Before you ask, this table was not used for anything else.

For your additional amusement:

• A long/bigint holds 19 digits, not 11.
• The Numbers table had hundreds of thousands of rows. You only need 364 numbers to parse the maximum string length that could be passed.
• There were mysterious gaps in the numbers table. None of them were in the range that would have affected this procedure, but…c’mon.
• The Numbers table was rebuilt every time the system started from hundreds of thousands of INSERT statements…in multiple databases.
• Why you need to use a double-byte character set for a string that holds only digits is beyond me.
• The team that came up with this was supposed to be our crack team of Enterprise Infrastructure Developers.

I’m posting this story and, soon, others I can bring myself to remember for a few reasons:

1. We have told them plenty of times to developers joining the team. Pointing them to a link will take a lot less time.
2. I want to remind myself how good I have it now, relatively speaking.
3. To, hopefully, stop myself from falling into the optimization trap.
4. Poking fun at this helps me get rid of the bad feelings associated with it.

Update: A co-worker corrected some of my code. SUBSTR is 1-based, and my WHERE clause was jacked up.

I was lucky enough to get an invitation to Pownce from Patrick. I like some of the ideas in Pownce (e.g. file sharing, threaded replies), and it will be interesting to see if they can overcome the inertia of twitter to have some success in the micro-blogging space.

One thing that is nice about Pownce is the client they have written using the Adobe AIR runtime, which functions a lot like Twitterific. I did find one bug, though. If you have colons (and maybe other “special” characters) in your password, you get an error when logging in. Probably something to do with URL encoding. If you change your password to alphanumeric characters, it works like a champ.

The latest on the reading list is Programming WCF Services from Juval Löwy. I’m having a real hard time maintaining interest in this book for a variety of reasons, but I’ll save the review for when I’m done.

I was only in the first paragraph of the preface when I hit a statement that sums up how I have been feeling about Microsoft development lately. In Juval’s own words:

Then, in July 2002, during a C# Strategic Design Review, the remoting program manager outlined in broad strokes plans to rework remoting into something that developers should actually use.

Now, Juval is not a Microsoft employee so much as a Microsoft shill; so, nothing he says can be taken as anything official from on high. However, I think that one statement has focused my frustration enough that I can articulate what has been bugging me. It shows a complete and utter disregard for the people that have been building their products on the .NET platform by Microsoft and their evangelists. This type of behavior can be seen in almost all facets of their development tools and technology stacks (e.g. distributed systems, data access, web applications.) They come out with yet another new solution to a problem only to turn around and rework it from the ground up and tell us what a piece of crap that last implementation was.

Outside of the standard disclaimers on alpha and beta software, I have never seen or heard Microsoft say that we shouldn’t be using their current technology stack. If remoting was so bad (I do think it was and still is,) why didn’t they caution us against using it? Why do they continually come out with shiny new toys that require the people driving their success to rewrite mountains of code?

The simplest answer is that most of what they put out does suck. While there have been some real “gems” thrown out there for people to risk their business on, I don’t think that completely explains it.

The second simplest answer is that Microsoft has shareholders and loads of salespeople and middlemen to appease. They cannot survive without a constant stream of revenue pouring in. They could accomplish that by being the hands-down best platform out there. Instead, they choose to feed the MSDN beast and get developers whipped into a frenzy about something that will require more upgrades, training, etc. Incremental, but substantial, improvements with a lot of thought put into maintaining compatibility with existing code do not keeping cash flowing into the maw.

A lot of people have written about this. Some of Microsoft’s own people have had moments of sanity. I just wanted to register my disgust. If anyone from Microsoft comes upon this, know that you’ve lost another “heart and mind.” I have unwittingly done my part to push your products and agendas in the past. I won’t be doing it anymore. Will I stop using the .NET platform altogether? No. Will I avoid subjecting my employers and clients to change for change’s sake? Absolutely. Will I make every reasonable effort to get them to consider alternatives? You better believe it.

Update: As with all things, I should have looked to Looney Toons for an appropriate analogy. We developers are Elmer Fudd, and whatever Redmond is pushing is Bugs Bunny in a dress. We just keep falling for it every time.