Why develop internal libraries for internal applications

libraries

I'm having difficulty understanding why you should develop internal libraries to be used exclusively for developing internal applications. I appreciate that if I want to use software that someone outside the organisation has written then they can send me their header files and .a or .so files and I can just link it to my project (assuming they are compiled in the same environment).

But why should an internal library be developed just to be linked to an internal application when I have access to the header and implementation files and can just include them in my source tree and compile them all together?

In other words: if some source code is written, how do you decide if it should be compiled into a binary library and linked to your application or just included in the project's source files and compiled regularly?

When I say 'include' files in each project, I do not mean to copy and paste each file into the source tree of the project currently being developed. I mean developing some directory/library (separate to any project) containing common source code that can be included into a project's files in the usual way, i.e. #include.

p.s. I'm talking about c/c++ development here for multiple desktop applications.

Best Answer

There are numerous reasons to create libraries & shared libraries, (in .dll or .so files) even for internal usage:

  1. Re-Use across projects is much cleaner
  2. Separation of responsibility - part of your code may be more suitable different developers or teams
  3. You can benefit from improvements in the libraries that other teams make without having to locate the specific code
  4. Faster build times, if the library is stable it doesn't need re-building.
  5. Disk Space - you can have just the library and the headers in the project
  6. If you use shared libraries you can make memory savings with only one copy loaded into RAM even if several programs are using it
  7. You generally end up with better documentation and testing of the libraries
  8. Cleaner design and code - thinking about structuring things into libraries should result in related groups of functionality in each library and you tend to separate generic code, into the libraries, from the application specifics, in the app.
  9. If you have proprietary algorithms in libraries you can restrict access to the source, e.g. not allowing contractors or out sourced teams to get at the source.
  10. Library code may be placed under a different licence to the Application it was originally written as a part of, some companies have even been known to Open Source libraries that they are proud of - gaining major kudos in the Open Source community and sometime major enhancements contributed back.

Some companies even have an accounting practice where projects that create libraries get some reimbursement on each re-use.

Related Topic