I’m on the opposite side of the spectrum from GrandmasterB. To me, this is a buy versus build question.

From my perspective, my time and effort can be represented by a cost. The question then becomes, when it there sufficient return on investment to build a framework? (If I’m working for a client, I think about these questions from the client’s perspective.)

Here are the questions I ask myself:

• Does the framework already exist?
• If I build this framework, is this something I want to be known for? In other words, is this framework a differentiator for me?

Oftentimes, I find the answer to the second question is no. I’m working for a healthcare company now. They don’t have a desire to be known as the developer of a best-of-breed scheduling engine. I should outsource the development and maintenance of that framework.

However, if we’re talking about a pricing engine, that’s the company’s bread and butter, so I should definitely focus my energy on making a superb engine.

My general rule is, if its a product, or an important part of the product, make it myself where possible. If its not core functionality, or is acting in support of a business (something only used inhouse), go nuts with the frameworks.

Many of the applications I make are long term investments – 10+ years, possibly – and they are products being sold to customers (thus my responsibility). So being able to ‘quickly’ get going using a 3rd party framework isnt as relevant for me as it would be to someone who’s making a dozen apps a year. So I’m generally not opposed to diving into the nitty gritty and making my own. Over the product’s life time, a few extra weeks getting a custom framework/component going wont matter much. But it may mean a lot fewer headaches and fewer brick walls since its designed specifically for the application.

It seems to me that a framework is a collection of libraries. Once you have a bunch of them and you make sure they have consistent APIs and play nice together you bundle them and call it a framework. But you should be making sure that all your company’s libraries have consistent APIs anyway whether you use the F word or not.

Frameworks tend to get written ‘accidentally’ when someone looks at all they have and say ‘hmmm, this bunch of stuff can be useful to others’. That is unless you’re a company that ships source, or you’ve been explicitly asked to write a framework. Doing stuff for the sake of doing stuff is always a bad idea in programming.

Whatever you do, make sure you are not re-inventing the wheel, especially as a square.

If you’re like me, your job is to provide business value as efficiently as possible, not to debug and tweak pet projects. If there is a widely used framework that does what you need, don’t waste your time reinventing the wheel, as the widely accepted framework probably does it better than you can. They’ve had more time, experience, and resources to develop it.

Over the last 6 months my company recently had me write 2 different applications that do a lot of similar things. Recently I’ve been asked to write a 3rd similar application, and there’s a lot of room for more similar applications in the future. Since no one has developed a framework for the proprietary technology I’m working with, I saw no other option but to develop my own framework. If I don’t develop my own framework, I will spend a lot of time repeating myself, and that will be a waste of time and money.

I think this is the key as to whether it’s worth it to build your own or use someone else’s. If you have to waste a ton of cash over the next few years, or build a framework, then build the framework.

It’s very difficult to accurately predict what an ideal framework would look like without having first built something. Harvested solutions are generally better than foundation solutions (thanks for the links caarlos0), because your code is not built on guesses about what the client programmer wants, but actual experience. Read: Emergent Design.

That said, there’s only one reason in my mind to build your own framework: if you’ve done the same work twice and are probably going to do it several more times, and nobody has done the work for you.

I try to get the most miles from available frameworks and tools on any new project. After the project has evolved, maybe burned in for a year or two, then replacing the parts of the framework that cause the most pain is a reasonable choice. Unless your business plan centers around creating a new framework, I wouldn’t plan to write your own.

When a piece of technology really fails, I keep a list of specific complaints and ideas for how it should be redesigned to work better. In the short term, this “manifesto” gives me an outlet for my frustrations while still using the existing framework. In the medium term, it helps me identify the worst pain points so that I don’t waste energy fixing minor issues. In the long term, the manifesto can become a design for a partial or complete replacement, or a feature list for choosing a new framework.