Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Today some friends and I started discussing frameworks..

Some of us strongly believe that in 99.9% of cases, writing a new framework is a bad idea. We believe that probably some of the millions of frameworks out there should fit our problem, and if not, some hack, API, or configuration should be enough. If not, we think that contributing to some framework, suggest features or something like that should be the best solution. The 0.1% is when none of the frameworks fit to our case.

But, some of us say that it is better to have an "internal corporate framework" (for example), because it's faster to fix issues, creates a 100% fit with the app, because of the "learning" factor (when you improve your skills building a framework), etc.

I think that to go out coding frameworks like there's no tomorrow is not the right way. I've seen a lot of small teams building their own framework just to spread the word: "we built our own framework, we rule, bro". Generally, the framework is crap, without any documentation, and only works for their own applications.

Opinions are opinions, devs are devs, without the intention to start any kind of flame war, I ask:

What do you think about that? What parameters you consider when building a framework? What do you think about all this?

share|improve this question

closed as not constructive by Jim G., Eric King, Walter, gnat, ChrisF Nov 8 '12 at 23:01

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

6  
Write games not engines. –  Telastyn Nov 8 '12 at 18:57
1  
Are you aware of the effort required to write a Framework? Would it work in 2 years? How many people will be responsible for maintaining it? How about testing backward compatibility? Will you spend time to document it? Will you have training courses for it? –  Emmad Kareem Nov 8 '12 at 21:27
    
@EmmadKareem: What if the answer is yes? Would that mean they should do it then? –  Omega Nov 8 '12 at 21:31
1  
@Omega, Personally I would never do this unless I have the skills and resources as well as good reasons why everything else out there does not work for me. That is more research than development to me. Also, I am not sure the business will wait form months until this finishes before building their applications. –  Emmad Kareem Nov 8 '12 at 21:36

5 Answers 5

up vote 10 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
1  
but, you build a framework for a new app before start building the app? In short: Do you build Foundation or Harvested Frameworks? –  caarlos0 Nov 8 '12 at 19:44
1  
Generally as I'm building the application the framework evolves with it. –  GrandmasterB Nov 8 '12 at 21:12

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.