23

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, ...)?

Improve this question
2

7 Answers 7

Reset to default
16

Answer to why:

  • License issues
  • Company specific requirements that didn’t exist in current frameworks
  • 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.

Improve this answer
8

Why build your own?

  1. because it's never been build before (rare, but a possibility nonetheless)
  2. because you want full control.
  3. because you only need a little bit of functionality so that it is cheaper to build it yourself

Why not build your own?

  1. you don't have the time to do so
  2. it's probably a lot cheaper if you buy an existing framework
  3. you save a lot of time and can get productive a lot faster
Improve this answer
7

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.

Improve this answer
3

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:

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

  2. This is just a case of 'Not Invented Here' syndrome

  3. Your current setup will not be able to successfully create this framework in a reasonable amount of time for a reasonable cost.

Joel Spolsky wrote a very good article on the matter: In Defense of Not-Invented-Here Syndrome

Improve this answer
2

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.

Improve this answer
1
  • 1
    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 Sebrechts
    Jan 12, 2011 at 10:31
2

We've got a pretty mature framework where I work. Here's a summary Foundations Framework

One of the key reasons for using it is stability. We're not beholden to Microsoft or any other supplier who are driven to add new features and complexity year in year out.

(My own views, not that of my employer etc etc.)

Improve this answer
2

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.

Improve this answer