Alas, poor CLO!

On returning from a wonderful holiday in Melbourne I learnt that Aderant have finally admitted that they are terminating CLO, the product on which I used to work when in their employ.

Given that the entire development team responsible for creating CLO were retrenched in one fell swoop just on two years ago I have to wonder at their delay in making this announcement. I found no clue in the scripted Power-point that they put up on their web site (http://www.aderant.com/webcast ). Only more questionable statements that reminded me how happy I was to leave Aderant's employ. And how extremely happy I am that I am not a customer.

For the record, CLO was not some ancient technological relic. It was a legal practice management system with a component written in Java, and a component written in a 4GL.

The Java component was for front office work, and thus was a rich client application that used a network launching protocol that allowed users to start using it by simply selecting a link on a web page.

Underneath the rich facade the CLO Java client had been built as a strict implementation of the Model/View/Controller pattern. As such the business rules and database access were separated from the GUI by a mediation layer. This was deliberately done so as to enable one to easily replace the rich client GUI with an HTML one, thus allowing CLO the future option of running as a proper web application.

The use of Java meant that the front office component could run on more than just Windows: I personally saw it running on Linux, Solaris and Mac OSX. Sadly Aderant chose only to support it on Windows.

Not only did the front office component run on different operating systems: through the use of JDBC escape codes CLO ran against both Informix SE and MS SQL Server. For a while Oracle was also a supported database, but for various reasons it was decided not to continue with this option.

The final point to note about the Java client was that it had a very modular architecture. The intent was to develop a framework that supported screens that could be "plugged in". The Eclipse IDE shows the power of this approach. These screens could be simply assembled by generative techniques based on what we had learnt from using the 4GL.

The 4GL was one of the most productive environments I have ever seen. With a flick of a switch one's application could be transformed from a rich client to a web based one. Or one that ran in a terminal. The nearest thing to it that I have seen is the Rails framework that is now gathering rave reviews for it's productivity. We did have some issues with the 4GL, but these I will set aside for another discussion. 

All of the above was done by a team that at its largest had only 5 developers. The secret to our productivity was the heavy use of open source tools and libraries, and agile techniques.

We were financially and resourced starved by the company, and so to survive we were compelled to go down this path. This experience turned me into a true believer of small teams, open source, and agile development techniques.

Given this I consider CLO itself to have been a prime candidate for exposing as an open source product. Its end closes this opportunity.

Although I haven't worked on CLO for a number of years now I still felt saddened by the formal declaration of its end.

This then serves as my eulogy to an application that had so much to offer. An application that was terminated by people who's vision of the future of software is very different to that of those wonderful people who worked on CLO alongside me.

1:37:02 PM