Over the last couple of years I have been involved with companies that have built their own frameworks using the .Net Framework to encapsulate such functionality as data access, security, and even UI elements such as page management and common list box controls. In their purest forms I think frameworks are great to have and can bring a lot of positive things to a project and a development team, but in practice what I seem to be finding is that frameworks turn into a brick wall to getting things done, a crutch for bad habits, and a roadblock to innovation.

Here are a few positives that come from a framework when done right:

• Concise code where common functionality exists in one place.

  Duplicate code means duplicate bugs, more lines to dig though, and more lines to tests.

• A strong foundation for projects that allows milestones to be reached quicker.

  Time is money in every industry and what ever gets you in the right direction the fastest will save you money. (Notice I said the right direction.)

• An abstraction layer so that new developers don't need to learn everything before getting started on a project.

  It can take new developers time to get up to speed and contribute to a project. If they have a framework that abstracts the details of certain areas away from them to start out they can more quickly begin adding value.

• A standardization that guides projects in a consistent manner.

  Assuming the framework is consistent, then the way you interact with it helps to structure your program and give projects a similar look and feel.

• A time tested code base that evolves to be trusted and bug free.

  Well maybe not completely bug free, but overtime and use we start to trust code more and feel more comfortable deploying it. If a framework gets a good work out on multiple projects then it tends to become fairly stable.

Here are a few of the negatives that I see that really happen with frameworks:

• Too much stuff gets put into the framework that doesn't get used.

  People start rolling stuff into the framework because it has potential to be reused, but even if the item can be reused, it involves so much customization for a particular client or project that it is no longer the original piece.

• Items go into the framework that aren't documented and in turn the functionality gets reproduced somewhere else.

  I'm starting to see this one over and over again and it is partially a side effect of frameworks getting too big. People don't know what's in the framework, whether it be because they are new or simply because the framework is so big and has so many people working on /with it. People end up reproducing the same functionality someplace else.

• Existing framework functionality is not maintained well and becomes a hindrance down the road when new technology comes around that doesn't mesh well with the framework.

  A framework in .Net 1.1 becomes a framework in .Net 2.0, which then turns into a framework in .Net 3.5, but the code stays the same. Technology advances and the framework elements need to as well, but the mentality of "if it ain't broke, don't fix it", seems to hang out with frameworks.

• Developers never learn how to code outside the framework.

  I actually worked with a young developer at a previous employer who, when it came time to leave the company, realized that he didn't really know how to get data out of a database without the framework. I considered him a decent developer for his level of experience and a person with a lot of potential, but he'd been stuck using the same framework for all of his short development career so there were many things he never needed to know how to do.

• Old, Fat, whiny people get worked up even at the thought of making a change to the framework. (They're not always old or fat, but they tend to always be whiny.)

  Really is there anything else that needs to be said here? You know the exact type of person I mean and if you don't then say hi to them in the mirror while brushing your teeth in the morning.

• The framework becomes the solution to every project even when it shouldn't be.

  This is the using a sledgehammer to kill a fly type problem. People get a one track mind and big or small the framework is the solution to every project's needs. Worst yet, project specifications start getting tailored to what the framework can and can't do.

• New developers don't feel empowered to make changing or additions to the framework.

  This doesn't even necessarily need to be new developers either. Frameworks seem to take on this bigger than life image that makes people feel like they are unworthy to make a modification. Either the developer modifies their code in a way they didn't want to in order to interact with the framework, or they do something crazy like copy the functionality out of the framework into their custom project and make changes to it. I've seen classes that were directly copied, with the namespace even duplicated and then minor changes being made to the copy to handle functionality that the developer wanted.

• The framework is rigid.

  Come on; mark a few methods virtual people!

Well I know I listed a lot more negatives than positives, but the positives definitely score highly. Having a reusable framework that handles a lot of common scenarios that come up with your projects can really help shorten the time to delivering a milestone. At each employer that I have worked at the projects during that time were fairly similar, needing the same type of functionality, and these types of scenarios benefit from a quality framework. Projects can get from point A to point B much faster, which translates into less money. Client and managers always like things to cost less.

I think the best solution to the negatives is to have individuals that have the key responsibility to maintain and grow the framework. Without individuals that have defined ownership in the framework it becomes a tool that is neglected. The "regulation" of the framework needs to fall someplace between a communist leadership and a capitalistic society. An individual utilizing the framework needs to have input into what is going on and provide feedback into what is needed, but in the end there needs to be a smaller group of individuals who decide what should be included and what shouldn't be. The framework in general is going to be driven by what developers need for a project and a client, but the framework needs to expand beyond the needs of a single client and project. Contrary to what some people believe, I've noticed in my career that if there isn't someone to go to that provides the firm yes or no, then nothing tends to happen. Problems get discussed, solutions get discussed, but nothing goes forward. Either no one feels empowered to take the reins or no one wants to be the fall guy if things don't work out.

Overall, I really do think a framework can be a positive thing, but it needs to be managed and budgeted for just like any other project the company works on, especially if it starts to become an integral part of most projects that are being done.