Embrace the framework!

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.

Neccessary Abstraction?

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.


  • Good point, from your premise of 'rejecting the framework'. However, consider another premise -- ingorance of the framework, often reimplementation of types is simply becuase folks don't know what exist already implemented.

    The framework is rather vast, and if you are new to .NET, but experienced in other tools this is a natural mistake, no malice or arrogance -- just a rather normal preference for 'coder' developers to code rather than read. People will pick what they prefer when nobody is forcing change :)

  • I believe a lot of that reinventing-the-wheel comes about, ironically, due to project deadlines. Developers are given X hours to complete a project. Even though they know there are new, improved tools to accomplish the task, they aren't familiar with them and they know they can get it done "the old way", even if that means writing some unnecessary code.

    Another place where it occurs a lot, in my experience, is where code is written using an older version of a framework and that code, which ain't broke so it ain't being fixed, remains part of the solution through several successive framework upgrades.

    An example I've seen of this with .NET is that lots of programmers using .net 1.x created type-specific container classes (e.g. a StringArrayList). When generics were introduced, many of those type-specific container classes would instantly fall out of the "embrace and extend" camp and into the "reinventing the wheel" camp.

  • WTF!!! Great post;) Thanks...

Comments have been disabled for this content.