When you know that a program has been over-engineered

From time to time I have to be reminded what is bad software engineering. And it usually happens by accident, reading an article that was about something completely different. This morning, it was this interesting article on ComputerWorld:

Free Windows XP tuneup: Put new life into an old workhorse

Look at the trick to add "Copy to Folder..." and "Move to Folder..." to your context menu: you go to the registry and add some completely meaningless GUIDs somewhere and... magic! If somebody on the design team decided to add this capability, you either should have put it in a structured menu to add this, or just have removed it from the system altogether!

The other tips are a little bit less worrisome. Interesting article. If my main operating system wasn't a Mac OSX, I would probably use some of those hints.

Oh, and don't think that I consider the OSX great. But it's very simple. It does have some "hidden features", but they usually don't require knowing magic keys here and there. Just digging through menus you didn't know existed, or calling command line tools.

It all always reminds me of the horror that I felt when I had to code using MFC. I bought the great The MFC Answer Book and was shocked by the amount of hidden and under-documented features (well, this was back in 1999 - maybe some things were documented after that) that just did magic to your applications. Things like (this is a fictitious example): "want to create a window with three panels, where two are static and a third can be resized? Just override this "CMainFrame::OnWindowInitialization()" and return "FALSE" and it will just work. Huh?

Anyway, I'm glad that's something far in my past. And also far in Microsoft's past (it's still supported, but there are way better ways of building "rich" UIs right now in Windows using .NET)