Java Library Management

Question

My organisation is just getting into Java development. We are keen to maximise the re-use benefits of Java and there is potential for a wide range of common components across projects. We will have 3 main environments: development, acceptance and production, on separate servers. We will soon have a number of separate projects and developer teams. We want to avoid getting into a situation where there are lots of libraries with incompatible versions of similar class files, that will ultimately end up as a mess for someone to clean up.
There does not appear to be much guidance material around that deals with this type of Java management issue. Can anyone point me in the right direction?
Thanks
John Franze
[email protected]

Answer 1

Hi.
The first thing to realise (which it appears you have) is that reuse does not happen on its own. The reasons for this are political, sociological, psychological, organisational, etc...
If you are serious about reuse, then your organisation will have to:
a) encourage developers to reuse existing stuff
b) encourage developers to develop reusable stuff
c) support the management of reusable stuff with suitable infrastructure (a component library for example)
Now, if your organisation is intending to use any metrics like 'lines of code produced' then you will kill (a) completely. So be very careful about what you measure.
If your organisation is intending to hassle developers to get their project task finished and move onto the next one because their current project has aggressive deadlines to meet, then you will kill (b) completely.
Also, be aware that developing reusable stuff typically takes about 3 times as long as writing stuff ad-hoc. Also, writing re-usable stuff is generally hard until you know how it's going to be reused. A common approach is: write the specific form of the code. If you need something similar again and you can't see how to generalise the first form immediately, then write it again for the second time. If you need something similar a third time, then you have two working examples of the component and one requirement for a slightly different form so you now know enough about what the general form is to make it economically viable to develop it.
My last piece of advice is: you need somewhere to put your components where they are locatable by keyword search or something. This might be a separate department that acts as a library/librarian.
You might find some useful writings in the links that you will see here: http://dir.yahoo.com/Computers_and_Internet/Programming_and_Development/Tools/Software_Engineering/Software_Reuse/
Good luck.
Lance
Lance Walton - [email protected]
Team In A Box - Software without Tragedy
http://www.teaminabox.co.uk