When is a 'core' library a bad idea?

Question

When developing software, I often have a centralised 'core' library containing handy code that can be shared and referenced by different projects.

Examples:

• a set of functions to manipulate strings
• commonly used regular expressions
• common deployment code

However some of my colleagues seem to be turning away from this approach. They have concerns such as the maintenance overhead of retesting code used by many projects once a bug is fixed. Now I'm reconsidering when I should be doing this.

What are the issues that make using a 'core' library a bad idea?

Answer 1

Core libraries are bad when they start suffering from feature creep, and very bad when they aren't well maintained.

You might find this article interesting for an extended view point (which I agree wholeheartedly with):

http://www.yosefk.com/blog/redundancy-vs-dependencies-which-is-worse.html

---

Don Knuth: "To me, 're-editable code' is much, much better than an untouchable black box or toolkit... you'll never convince me that reusable code isn't mostly a menace."

Answer 2

Using the idea of a core library being bad when multiple projects depend on it, is like saying you shouldn't use jQuery for the web, libxml in you *nix apps, or any other framework or library. Look at the entire ecosystem of modern development (DRY, OOP, etc) and every single app is built off a set of libraries and frameworks.

What can be bad is if you don't have any type of unit tests, you don't regression test and you don't use any type of API/ABI with your library. If all of your applications have proper tests, your library has proper testing, and you make sure if you break function calls you update api version number appropriately.

For complete coverage, what one would probably want is when changes are made to the Library, you can run a set of tests that will verify the API hasn't been broken, and that the execution of all the code is bug free. Then you can pull in the latest library update into your application and run the same set of tests. If you update the API, then it should be documented so you know what you need to do in your application to update it. Either way, when you run the tests for your application, then you can be as confident as you are in your tests that nothing has broken.

When using jquery, mootools, whatever javascript library or framework, you can't just blindly use the new version, sadly you can't even with a minor 1.6.z release sometimes.

Answer 3

A core library can be bad when multiple projects depend on it, not only do you have to test any changes to your core but you also have to regression test every single dependent project. Secondly, your core APIs can never change because you will have to refactor every dependent project. The more projects that use your library, the deeper the trap.

Another problem is the tendency to start throwing everything "common" into your core library, bloating it and making it harder to pull in for small pieces. I'll just say that once upon a time I heard of a place that became afraid to touch any of their numerous core libraries, the overhead of QA regression testing was so great.

Instead, maybe you can create a code snippet resource to let project teams search and pull in the code they need and sever themselves from any maintenance or regression issues? That's what I do at home, anyways.

Answer 4

One point not yet mentioned is that any code is going to have dependencies on something, even if it's literally the only thing running in the ROM of an embedded microcontroller; if the manufacturer of the controller changes some behavior which the code relied upon, the code will either have to be modified to work on chips manufactured after the change, or else manufacturers of the device which uses the code will have to somehow acquire chips which do not incorporate the change--possibly paying a price premium for them.

Using a library to perform various hardware functions may mean that code is now dependent upon a library whereas it hadn't been previously, but it may also eliminate dependencies between the code and the hardware. For example, a chip manufacturer might promise to supply a library for all present and future chips which will always perform certain I/O functions a certain way. Code which uses that library to perform those I/O functions would become reliant upon the manufacturer to supply appropriate versions of that library, but would no longer be dependent upon the manufacturer to use the same hardware implementation of those functions.

Unfortunately, it's often hard to know which is the correct approach for future-proofing code. I've seen cases where a chip vendor changed the way a library worked (so as to accommodate new chips), even when it was being used to access a chip which had changed. I've also seen cases where a chip manufacturer changed the way its hardware worked, but supplied libraries were adjusted appropriately, so code which used a library routines would continue to work without change, while code which accessed hardware directly had to be adjusted.

Similar situations exist with Windows applications. Microsoft sometimes loves to change the way applications are required to do things; code which uses certain libraries for such things may be upgraded simply by updating the library, while code which does not use libraries that get updated for them must be updated manually.

Answer 5

They have concerns such as the maintenance overhead of retesting code used by many projects once a bug is fixed.

If you have a comprehensive set of unit tests for the core library; that is not an issue. No code will be checked in unless all tests pass. If you do introduce a defect you write a failing test to reproduce the defect and fix it; then you'll always be testing for that error as well. Forever.

Also the functionality you describe is very easy to write unit tests for.

As a side issue you might want to have more than one core library so you don't have to include the RegEx code unless you want to.

Answer 6

Writing libraries for basic things like strings and linked lists is quite silly in this millennium. Use a batteries-included programming language which has the core functionality already in it.

If you like writing core run-time support libraries just for fun, then design a new programming language. If you do that in an application, then essentially you're growing a language out of its side.

Besides, hasn't someone already written N different core libraries in the language you're using? Researching existing frameworks and picking the best-suited one may be better use of time than doing it from scratch.