I could have kicked myself last week. I was running Visual Studio 2010 in a VMWare VM, and it kept locking up – it was driving me batty. The problem started out as one of those “once every four of five hours” kind of lock ups, but it eventually got to the point where I’d open the solution and click “X” on one file, and I’d be locked up.
I tried everything. I googled the problem till the cows came home — nothing. I tried updating VMWare tools. I tried rebuilding the VM. I tried 64-bit and 32-bit. I even uninstalled VMWare Server and installed VMWare Player, thinking that the lack of Direct-X support in Server might be causing the WPF-based VS2010 some issues. No dice. Nothing worked.
Just about the time I was ready to chuck the whole works out the window, a nagging memory surfaced. Somewhere in my distant past (ok, it was three or four years ago), I remember having lock-up problems with Visual Studio 2005. I never did figure out what was causing the lock-ups, but I had a sure-fire workaround: just delete the .SUO file for the solution and re-launch.
So, having already exhausted all of my “good” ideas, I gave it a try, and just like that, I was back in business.
Wouldn’t you think that at this point, there’d be some way for Visual Studio to detect that something was pretty badly hosed in the .SUO file? Me too.
If you’re hypothetically considering changing the interface of your application so completely that users can’t find the stuff they need in the places where they’re used to finding it (Office, I’m looking at you…), you might be expected to have your users need to use “help” a bit more than normal.
And if you expect your users to need to use your help system, and if you choose to make that help system an internet experience, and if that internet experience is going to use a browser that’s had so many restrictions placed upon it in the name of security that you can’t sneeze without seeing some sort of exception (IE, I’m looking at you….), you should probably consider the likelihood that your users (already frustrated because they can no longer accomplish something that they used to be able to accomplish on their own) are going to encounter a help system that looks something like this:
For the last couple days, I’ve been helping another project team track down a memory leak in their app. Memory leaks always seem to show up at the most inopportune moments, of course, and this one was no exception.
This memory leak, however, was self-inflicted. The source of the memory leak appears to be rooted in an open-source project the team was using to manage detached POCO’s. The detached POCO’s, it turns out, weren’t needed by the project when they were built into the architecture, but were built to support a yet-to-be-built offline client. The project team met the anticipated requirement with a clever project that met a widely-recognized need in Entity Framework 3.5. For those shops that absolutely needed this functionality, there weren’t too many choices, and this one was right at the top of the list. The extra functionality, though, added code and complexity, and in this case, a memory leak.
As a final insult, it now looks like this offline client won’t be needing the detached POCO’s, after all, and on top of everything else, the POCO support project is now essentially deprecated in favor of native support for POCO’s in EF 4.0. The lesson is repeated every day in development shops around the world: someday never comes (you had no idea CCR was singing about software development, did you?).
Everyone who designs software has done this, but if you’re designing software, think about these points to avoid this all-too-common pitfall:
Beware the temptation to build for future requirements. I’ll be the first to admit that it’s pretty tempting to put in that hook or extra layer when you just know you’re going to need it, but consider the risk when you do this. Requirements change all the time after they’re real, and the ones that aren’t real yet are even more tenuous.
If you’re using a third-party tool or library, open-source or not, be sure to assess the present and future stability of the software. On Scott Guthrie’s blog today, he announced a new View engine called “Razor”. Buried in the article was a little gem of a quote: “Razor will be one of the view engine options we ship built-into ASP.NET MVC.” If you don’t have a quote like that for your library, you have to factor in the risk that the software you’re counting on will go away (perhaps with little notice).
Be especially vigilant about architecture decisions that permeate your software deeply or create extra complexity in your design. These decisions are critical and difficult to correct later.
When you build for the future and guess right, you might wind up looking like a genius, but be careful, because far more often, “someday” will bite you.