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.

Hello Mr. Osborn, how are you today….How's the weather there in…Iowa"….Please hold while I look up your information…Sorry sir, my computer is really slow today….Hold on while I go talk to my supervisor…..

Okay, I'm an introvert, I'll admit that, but isn't it time that email is elevated to the status of the phone call? In my opinion an email is simply an asynchronous phone call when it comes to business related conversations. I'm busy throughout the day and I'm sure everyone else is too, but I do have a few minutes of down time here and there when I'm waiting for data to load or a project to build and I utilize that time to get some other tasks done. What I don't have time for during a build process is to sit on hold or wait for a receptionist to look up some information. The weather is either too hot or too cold and I'm sure your kids are great. Oh, you're computer is slow? No, I don't want the credit protection plan. Half the time I am probably going to get someone's voicemail anyways, so why not just send them my questions in an email in the first place. Sure in some cases a phone call can be quicker or the urgency requires a phone call, but in most cases a few emails will suffice and it allows me to space out the time into the random free minutes I have throughout the day. Sure I could just put you on hold every time my build finishes and take you off hold when I am waiting on data to load, but most likely you would find that extremely rude.

The problem I am running into is that apparently other individuals don't consider an email on the same level as a phone call. Don't get me wrong, I don't expect an immediate reply, but there are a few things that I would like to be able to start expecting.

• If you're out of the office for more than a day, I would like to receive an out of office reply.
• If I send you an email before 2pm on a work day, I would at least like to get an email before 5pm saying that you are looking into it and when you will be getting back to me.
• If there's a document you need me to sign, then scan it and email it to me. If I don't have the time to call you then I sure don't have the time to stop by your office.
• Don't send any data like a credit card number or social security number to me in an email unencrypted. If you need that information then you won yourself a phone call (or I'll decide it wasn't that important).

Is that too hard to expect? Obviously there will always be exceptions, but I would say that they are pretty simple to adhere to. The great thing about email is that people don't really want to type very much, which is great because I don't really want to read very much, so they keep their answers as concise as possible. I think most people want that phone call initiated because they feel they are going to have to do a lot of explaining, but it is most likely the case that I'm not going to retain the big long explanation you provide over the phone, so just answer my question via email which I have most likely phrased in the form of a yes or no question and save us both some time.

Seriously, am I way off base here?

Today I set aside an hour and fifteen minutes and watched the famous last lecture titled "Really Achieving Your Childhood Goals" by the late Randy Pausch a computer science professor at Carnegie Mellon University. In August of 2006 Pausch was diagnosed with pancreatic cancer and he passed away on July 25, 2008. I encourage you to watch the lecture and then ask yourself the question "Am I achieving my childhood goals?"

I've been pondering this thought for about 6 months now, wondering if I have achieved anything that I intend to so far in my life. This is a tough concept to contemplate. I know personally that I find it very easy to know what I don't want to be doing and what I don't like, but I find it difficult to know what exactly I want to be doing. I think it is all too common that society expects us to clock in and out of our 40 hour a week job and we're suppose to believe that this is what it is all about. Is that really what life is about? If you found out tomorrow that you were going to die in the near future what would you do?

Personally I don't feel like I'm working towards a dream. What I am working towards is my mortgage payment, health insurance, and achieving society's expectation of being a standup citizen. I'm beginning to believe that by working toward these goals I am failing myself and my dreams and I think that this is the case for most people. We get stuck doing what is expected of us and locked into financial concerns that prevent us from achieving our dreams. Working towards society goals causes us to lose sight and motivation for our own goals. When this happens then was life really worth it?

I think that a lot of factors add up to us achieving our dreams. Knowing the dream – this can sometimes be the hardest. The daily noise seems to drown out the internal part of us that causes us to dream. I'm so busy accomplishing "tasks' during the day that the only thing I dream about doing is sitting down and doing nothing. Havingthe means to accomplish the dream – Accomplishing a dream can be a financial and time consuming task. Even when accomplishing the dream does not require a direct financial investment the time that is required for a dream could have an overall impact on things either financially or otherwise. Motivation – It's strange to not be motivated to accomplish your dreams, but the shear challenges faced in accomplishing a dream can affect the desire to complete it. Support from others – Support from others to achieve your dream can have a powerful impact. I've found that most people are negative towards the concept of me accomplishing my dreams, either because they feel it is impossible, or because the dream goes against society's norm. If one person I trusted pulled me aside and told me to per sue one of my dreams now it would probably be enough motivation for me to go do it.

Are you achieving your dreams?