Multi-Threading is Cool. Except when it isn't.

I've read quite a few articles and books that proclaim the benefits of multi-threading, and many people admire the beauty of a nicely threaded program.  I agree fully - a well-implemented threading server certainly can reap great performance benefits.  SQL Server is a wonderful example of this.  So much thought was put into threading in SQL Server that they implemented their own thread scheduler, pre-empting the OS threading model through some quite clever trickery.

However, sometimes people can go over the top with threading.  Really.

I've recently taken over an installation project at my new job.  It's a bit involved, as it installs several databases, sets registry, config data, and a bunch of other one-time gunk that installs normally do.  It was originally implemented in Installshield 5, with custom calls into C++ dlls, as was common in the days of installshield 5.  My task involves helping to drag this project into the 21st century, adapting it to windows installer using Installshield 9.

All's fine and dandy on the Installshield side.  The bigger problem I am having is that in the custom C++ code, there is some convoluted threading going on. 

Yes, threading.  In an installation project.  One might ask why.  I know that I have, several times, while cursing the assorted bugs that come along with this. (It's actually worse than simple threading - they implemented application windows to listen to a message pump so that child threads could send messages to the window.  Ugh!)

Threading is a good thing to implement if there is a performance issue, I agree.  But this is hardly the case in an installation.  The 5 or 10 seconds that one might save is hardly critical, and certainly not worth the synchronicity issues that are introduced.

So, for all you super-smart gurus out there who thing that cutting edge needs to be everywhere:  Think before you act.  Threaded installs may sound great, but they aren't.  Trust me.