The Trashcan

Some people, when starting a new project decide they need a "base library" of some sorts to put all the neat little tricks in that somehow were "left" out of the .NET Framework. They need some wrapper around some functions that do extra checking or they feel generic collections lack a couple of features or something like that.

First of all, I don't have anything against that, since I also think a nice function here and there can make the body of a lot of code more readable, more elegant. The truth is however, that this little base library quickly becomes the defacto container for everything that was deemed "unworthy of finding a true place".

There's a place for everything, and some of that stuff has some place elsewhere, but somehow the developer couldn't be bothered (or couldn't figure out) where to really put it. Perhaps because there wasn't enough time to think about it, or perhaps because that developer was lazy, considering that it might be a good idea to do this at "refactoring time" (which probably equals to "will never happen").

So this little library turns into a "trashcan" of stuff that doesn't belong there, stuff that has nothing to do with the other stuff. Sometimes that stuff might be shared among two different projects in the solution. Two is usually enough to decide that this thing needs to be "reusable". So after a while every single project in the solution has a reference to the trashcan, and every single project becomes really "dependent" on it. Without it, that project will not build. And then comes the time that someone wants to flex their "code reuse" muscles and decides that some part of the application is "reusable" within another app. But of course, the trashcan has to be shared as well, even though 90% of the trashcan is totally useless or even dangerous to that other application.

So fear the trashcan, people.