Reinventing the wheel

There are three kind of developers when it comes to library use:

1. Those who extensively use existing stuff to avoid reinventing the wheel,
2. those who do code the stuff on their own and try to reduce as many of the  external dependencies as possible and
3. those who do the easy stuff on their own and only for big topics (like PDF or MS Office file handling etc) they use existing libraries.

If you want to avoid reinventing the wheel completely then you will end up with a lot of library dependencies which often even do not fit well together (just think of the many different java logger frameworks available).

Neither the first nor the second extreme will bring the optimum result - at least not when you think long-term.

For example I was using ini4j to load inifiles (because I was under pressure) but later I noticed that the sections are internally stored in a way that you can not rely on getting them loaded back in the proper order. For the project where I was using it, order of the sections previously wasn't really relevant (that's why I didn't either recognize that ini4j was mixing them up occassionally), but then things changed and now order of some sections is relevant. So I had to change the underlying library. I took the chance to implement the inifile handling on my own. Why? Would I have been the developer of that library I could have changed the internal implementation who the sections are loaded in an instant. Without being really involved into the project I would have needed to read into the foreign source code (which unfortunately is always more difficult than reading your own code - if you did it well) and doing code changes that hopefully will not be rejected by the project owner (loosing it again with the next patch). I would have done this probably, if it wasn't urgent and if inifile handling wouldn't be such a core thing for me (I deal a lot with inifile style files).

And here it comes to a related topic:
You can get your code being written almost everywhere around the world, but the important questions are: If you need a fix or an enhancement,

• do you have a chance for direct communication with the developers (or how many levels of communication are in between)?
• how fast can you get what you need?

Of course, when using a big library that is widely used you may get a very good and stable code base, but bigger changes will not be easy to get quickly.

I have seen it plenty of times, that having the full source code available at hand is the only guarantee to get fixes or enhancements in time when you need them!

And there is another related topic: Progress
Sometimes it makes pretty good sense to reinvent the wheel - and indeed if you look at the wheel itself, it has been reinvented (or at least adapted) many times and looks very different depending on the core usage and environment. For IT or source code this means that for instance the same stuff must be programmed again and again when you change programming language or when newer and better technologies can only bring benefit when you partly rewrite the application.

I write this because often the thought of reinventing the wheel is labeled so negatively. Rewriting code parts or writing them yourself instead of using an external foreign library can make really good sense!

Related post: Bronze age of IT.