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.