House of Babel
Sometimes I get involved with a .NET project where I find code that is just so "different" from the norm that I wonder how it got to such an extreme state; Code that reinvents Configuration, Threading, File IO, DataAccess, or sometimes even primitive data types. It strikes me as a form of extreme arrogance that a developer could find even the most fundamental building blocks incapable of being used. In the end, I find myself babeling to myself incoherently as I try to trace, diagram, and divine the secrets of these "innovative" implementations.
Take the Mono project for example. Eventhough its intent is to create a parellel framework capeable of hosting .NET applications, the underlying API implementation often deviates to a very large degree from the Microsoft implementation. This isnt surprising, since most of this work is to support abstracting away all Windows platform details (GDI to GTK++, et al) so that multiple platforms may be supported. This type of abstraction is inevitable and required; No arrogance, its simply abstraction justified by neccessity (for the most part).
However, the projects I refer to above are typically not targeting multiple platforms nor appear to need such extreme abstraction. In many cases, its just abstraction for the sake of abstraction. In others, its an overzealous attempt to solve a problem that could have been overcome simply by overriding existing behavior, or plugging-in your own custom modules.
Why do people insist upon doing this?
I'm at a total loss for words.
Maybe I'm just missing out on the subtle joy of NIH syndrome...
A Pragmatic Philosophy
My philosophy towards development is simple; Embrace the framework, question everything, adopt the good, extend any limits, reject the evil, and finally consider reinventing or reimplmenting a new framework only when all other methods have failed and its not possible to do anything else.
Even in the end, when all else fails, you shouldnt neccessarily reinvent the framework yourself since there are a plethora of solutions (often well tested and open source) to nigh every problem if you go visit Google for a few minutes. Throughout your analysis you should take on an attitude of humility; assuming first and foremost that it is your own lack of experience and understanding that prevents the framework from functioning, not an inherent design flaw. Only once you can prove a limitation or failure via code should you consider rejecting the framework.