I would like to know why you decided to build your own framework in your company.

By framework, I don't mean few libraries you use often. I mean a specific way of building applications on top of it, with base classes, convention, etc.

So why did you built your own framework? How could you justify that to the person that employs you. Have you measure the positive and negative impact of it?

Regarding your experiences, did you notice that in some case a company framework produced real benefits, or on the other hand, increased costs of development (learning curve, debugging, maintenance, ...)?

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

6

I did not decide. It kind of created itself...
–
MchlJan 12 '11 at 9:14

7 Answers
7

The company wants to have control over support and maintenance of the framework

The architect didn't know better! He/she didn't know about that specific framework existed, so they decided to reinvent the wheel.

Update:

Enterprises prefer to reinvent the wheel rather than using "small" frameworks. By small I refer to framework that may have uncertain future. For example.NET framework is more secure choose for enterprises than a framework created by a small community. Enterprises need security because many of their application are business critical and also long lived. The cost of reinventing the wheel may be more in short terms. But the cost may be more if framework used in company application is deprecated and no longer supported, or licenses are changed. Here the company may have to throw out the current framework and put in another one.
Visual Basic is a good example of a language that is no longer support by Microsoft. And this cost companies billions since they have to start over with new development.

The only real reason to reinvent the wheel is if it is a business critical application. If your company will be using for some time to come. If this applications/framework/etc. will likely evolve beyond the existing commercial framework has to offer, then having company coders make their implementation is certainly acceptable.

The only real reasons against this are if:

The existing framework is well
maintained, fully suits your task,
and will well into the future.

I did that several times, to meet requirements not covered by existing frameworks (back then).

In most cases, those home-grown frameworks have later been removed by newer, fully-grown frameworks. For example, back in 2000, I created a Java web framework, in some aspects comparable to Rails, used to create a complex order entry system with several hundered forms. It worked well, but of course, a few years later, more mature frameworks like Struts and JSF made it obsolete. But back then, it was the right thing to do, it worked well and the development speed was impressive.

Another framework I've developed is still in use (and also in active development); the first version was written in 2004. This one is mainly used for intralogistics applications; the company that uses it still sees it as a distinguishing feature. The main reason to create it was to make it easy to create database-connected applications for mobile barcode scanners (running some flavor of Windows CE); it worked so well that the bosses decided to use the same concept for the PC software also, and, well, they are still happy with it.

In my post on when it is appropriate to reinvent the wheel I list a number of advantages of a reimplementation. I think those advantages apply especially for framework libraries. For example, it is often impossible to isolate the use of a framework library inside a small part of you application. Instead, they tend to dictate the structure of the client source code, and therefore it is desirable to have full control over the library.

Basically when you use the work of others, you add them as invisible employers or "extra hands".

If they are good they will help you. If not, you have to do their work in addition to your own - in other words maintain their code. This might be an unacceptable risk, but I would consider it very rare.

The keyword is to make the framework swappable, by coding to an interface. The most rigid interfaces in the Java world are the Sun specifications, which is proved by the servlet API.

Then I would not consider there being any reason for not using a framework.

It's helpful to look at the development process of whichever framework you adopt. Frameworks with a strong commuity and an open process, where as a user you can see everything that goes on, and vote to influence it, are low risk, especially if they come with source code (I try to avoid code I can't build). In that case developing an additional wrapper around the framework isn't necessary.
–
Joeri SebrechtsJan 12 '11 at 10:31