My point of view

There is a time in many successful IT companies when they just don’t worry about the money. They don’t have to choose projects as wisely as at the beginning, when any tiny mistake can bring entire company down. There is always a money buffer that prevents such a catastrophe. In such situations basic instincts focused on surviving are just ignored and self-confidence takes over. Managers start to think what can be done to increase the income and many times they are coming up with the idea of building better, faster, nicer (than commonly available) internal tools or even whole internal frameworks. Why? Because they feel like the kings of the world and nothing can stop them…

In the mouth of management “let’s build internal framework” sounds perfect. It will give us full control over the code, it will solve all our problems with previously used technologies, we will build our applications faster and better. But as always the devil is in the details and in this case ‘the detail’ is the implementation. These are the tips that I, as a developer using internal framework, can give you. Take them before it’s too late ;)

If you have another choice than building your own framework, take it

One thing is when the framework is built based on portfolio of existing applications. Extracting common components is quite easy then. On the other hand, it can also be built from the scratch. Then creating entire framework will be always more complicated than direct usage or adjusting any library. Like in a usual application time is needed to develop it. It must be decided which requirements are crucial and which can be postponed. Also not many developers will be involved into development comparing to really popular open source projects with lots of contributors.

Framework probably won’t be better

If manager thinks that internal framework will be better than open sourced library than he can be really surprised after first release ;) In open libraries there are thousands of users which find bugs and test many corner cases which authors can’t even imagine. Internal framework users are only internal developers. They’ll find some main bugs but probably there will be more bugs that no one will find which will strike badly on production. Moreover, open source projects have been already developed for many years (e.g Spring is here for almost 10 years) and it is unlikely to create better internal solutions even in a couple of years.

Framework probably won’t be faster

If e.g. Hibernate is planned to be replaced then there are two possibilities. The first one is to write everything from the scratch (very time consuming), or the second one, Hibernate can be wrapped with a new developed code. But when something is wrapped then it ends up with additional code that will take time to execute so it can’t be faster than the original. The second thing is “planned decrease of performance”. Writing e.g. your own serialisation algorithm isn’t easy, so it can be decided that because of a new implementation, performance, compared to common solution, will drop by 50% (it’s not my imagination, it really happened).

Development using internal framework won’t be faster either

Developer using new, fresh framework will have many problems with it. He will find many bugs and he’ll spend time to locate them which will block his main tasks. He will have no idea how to use all framework solutions because of lack of documentation (of course implementation of framework has priority over documentation). He will experiment or will pilgrimage to framework developers with simple problems. Then, many times it will occur that framework’s requirements are totally different than application’s that uses framework and developer will have to create workarounds to framework that supposed to be helpful (!)

Switching to internal tools is not very motivating

Working that way is very frustrating. You don’t learn technologies that are used outside of the company. You learn things you won’t use in other projects and companies. You won’t find any solutions for your problems on Stack Overflow or even Google. You won’t be able to estimate anything – who knows what bugs you’ll find during the implementation.

Problem with finding new employees

Last but not least is finding new employees. No one experienced in internal framework will be found. If a real guru in all common frameworks and languages appears he will be like a junior programmer when using internal framework. And there is a high probability that when such a guru finds himself not motivated he’ll quickly find another job. At the end the only employees willing to work with internal framework will be students.

 

I don’t want to say that every internal framework is bad. If you really have no other option and you have an experienced team to built it, it may work. The most important thing is to know what can go wrong and what will be sacrificed. Nevertheless, I’ve heard many stories where internal frameworks were described as a waste of time and money but heard of only one company with internal framework that helps to achieve the advantage over the competition. And what stories have you heard about internal frameworks?