Delete the obsolete

A week ago I was in the unenviable situation of having to dig through a large number of legacy apps and libraries in Java, C and VB to find references to a database attribute that was going to be retired. Examining just one file took a long time, since a file containing a dangerous reference might have been imported as a helper lib in other projects - and to make things worse, I couldn't immediately see if these projects were obsolete or not.

In my current project, my fellow employees have a very good overview of which systems are used where, and which versions are deployed, so when I am unsure I can always ask them. However, had they quit and taken that knowledge with them, I would have faced a combinatorial explosion of repository source versions, deployed versions, and production environments that would have made my task impossible; not just very hard and time-consuming as it was now.

For clarity and maintainability, if a system is obsolete you should always at the very minimum comment database tables, tag repositories and check in README files to the repositories that clearly show that these things are no longer used. Even better would be to move the data to separate "graveyard" branches/databases. I think the best of all would be to delete the obsolete files, since you can always reconstruct them from the repositories and backups in the extremely unlikely case that you would need them again. I understand if some people are reluctant to do that, the human urge to hang on to things "just in case" is strong.

It is a project management anti-pattern to keep obsolete projects and modules in your source repositories, and obsolete database tables on your servers. You will soon accumulate a technical debt which, like the debts in your bank accounts, will keep growing over time. Keeping track of possible dependencies between systems and components becomes progressively harder, and it will becomes increasingly difficult for new developers to get an overview of the architecture. More and more valuable development time will be spent on "the debt" instead of useful tasks. Developers will not have the courage to refactor, and this will feed the negative habits of adding stuff but never removing - not very agile.

Luckily the managers at my current company have been convinced to set aside developer time during the summer to clean up the source repository and move obsolete code to a separate view. At this particular company, I won't have the tedious task of searching through obsolete code again. For all our sakes, I urge you to do the same. :)

Hudson and ClearCase

If you want your company to be more agile and want to install a Continuous Integration system, but are stuck on Clear Case, here is a little howto. I am normally a Linux/Unix boy, but Windows was mandated.

Download and install a servlet container such as Tomcat. Secondly, download the Hudson war file. You can (should) define a HUDSON_HOME environment variable. Start Tomcat, deploy the Hudson war to the webapps dir, the "jobs" and "plugins" directories should be created in your HUDSON_HOME directory.

Either use the builtin plugin manager page, or if like me you can't get it to work, download the Clear Case plugin manually and put it in the HUDSON_HOME/plugin directory and restart Tomcat.

Go to http://localhost:8080/hudson/ and choose "Manage Hudson" -> "Configure System". Configure the Cleartool executable home (usually c:\program files\rational\clearcase\bin\cleartool), and other tools/services you might use for your projects (Ant, Maven, SMTP server etc)

Select "New job" -> "Build a free-style software project" and select a name, press "ok".

How to configure stuff here depends on how your Clear Case administrator has set up your system, but this is what worked for me.
Select the "UCM ClearCase" radio button and configure the following fields:
View name - select a new unique view name, for instance "hudson_myproject". This is the view that Hudson will create for you.
Stream selector - this is very project dependent, this is how I figured out my stream name: If you have the ClearCase Explorer tool, select "Toolbox" tab -> "UCM" dropdown -> "Join project" link -> select your project -> "Properties" button. Now directly under the project name you see a string somewhat like the following:
project:myproject_1.0@\servername
Then the following should be your stream name:
myproject_1.0@\servername
If you have checked out a project view before with CC Explorer manually to the default drive (usually M:) you can go to M: with Windows Explorer and rightclick on the directory there and select ClearCase tab, then properties. You should be able to get the Stream string from there too.
Load rules - Backslash + the path to a VOB (database file containing the project) just under the root of the project view. Again, if you have previously created a view using ClearCase explorer and mapped it to drive M:, go to M: and open the view directory there. Select one of the subdirs there as your "load rule". For example, I had
M:\myproject\src
so my "load rule" became
\src

Now press "advanced" button in Hudson config, and configure the following:
Additional mkview arguments - Here I had to use the -vws parameter to the mkview command, plus a UNC name. Something like this:
-vws \\companynetwork\clearcaseviewsserver\AD\myusername\
This is where Hudson will create the view directory, but the source itself will be checked out to, and built from, your HUDSON_HOME/jobs/jobname/builds/ directories.