Tomas Varsavsky

Steve Yegge (one of my favourite bloggers) recently posted about the maintenance problems exhibited by a large Java code base. I agree that software bloat is one of the biggest problems in our industry right now.

His proposed solution is to re-implement the 500,000 lines of Java code into 150,000 lines of a more concise language such as Ruby or JavaScript (ES4). This approach seems misguided to me because software complexity is not directly proportional to number of lines of code. The fact that 5 lines of Java can sometimes be compressed into 1 line of Ruby does not make the logic less complex or easier to maintain if they are essentially doing the same thing. In fact, I would argue that often 1 line of clever Ruby is actually less maintainable that 5 lines of Java because it requires a deeper understanding of what’s going on underneath the covers.

A good case study is Perl where developers seem to be a mind set of “how clever can I be” and write one liners that become indecipherable even by the author within days. You might be able to get away with this if you’re a gun developer working on your own but not if you’re working in an average team of average developers. I think Ruby has actually struck a nice balance between readability and conciseness and this is one of the reasons why its popularity has surged. Still, the thought of a 150,000 line Ruby code base scares me and would keep me up at night if it was left in the hands of average developers.

A code base with 1000 Java classes is just a complex as a code base with 1000 equivalent Ruby classes even if the number of lines per class is less. Reducing complexity and therefore increasing maintainability is all about applying good software engineering principles and frequent doses of my favourite refactoring — Delete.

I spent this week doing a proof of concept time-boxed to one week for a client that wants a new corporate intranet. The first step was to choose a technology stack.

I have experience with some heavy weight commercial Content Management and Portal products that play in this space but all of these are expensive and probably an overkill for a intranet. The majority of the client’s requirements are to do with basic web content management so I went on the prowl for Java open source solutions to the problem. I spent around three to four hours installing and playing around with some open source products that have enterprise level support available through backing companies.

OpenCms 7 — OpenCms is a web content management system and nothing more. It was trivially simple to install and get going with MySql. It gives you a tree view of your web projects and you can go about managing content in the same way that you would in a file system. You do your work in an “offline project” and publish changes in batch when ready. I found changing the look and feel and layout non intuitive at first but it was ok once I worked out that my site was based on the “templateone” module and most of the styling and layout could be driven from properties in the document tree. OpenCms supports XML content that you can define and author through an automatically generated web form and then access from JSPs. The bundled documentation is good and finding help online is easy.

Alfresco Community 2.1 + Web Content Management extension — Alfresco is a lot more than web content management system. At it’s core it is a document management and collaboration tool that is trying to compete with products like Microsoft Sharepoint. It has team spaces where users can author, manage, version control and share documents as well as participate in discussion forums. Users can access the content repository through a sleek looking web interface or directly from Windows using various plugins. Content can also be accessed through a web service API. The Web Content Management extension adds the ability to create web projects and publish web content. A really cool feature is the ability to deploy dynamic web projects (i.e. WAR files) that are developed outside of Alfresco. I tried this out by creating a simple web application using Sitemesh to control the layout. As a Java developer I found this much more in tune to my way of developing software. In terms of support there’s a website, a wiki and forums but I found it very hard to get useful information. Even something basic like installation instructions are incomplete and all over the place. Alfresco is more feature rich than OpenCms and with that comes extra complexity which led to frustrating attempts at implementing more complex things like XML based web content. Overall I was quite impressed with Alfresco and can see the potential to do some really cool stuff in it. Unfortunately, due to the learning curve, lacklustre documentation and short amount of disposable time I abandoned Alfresco as an option. I will re-visit it when I have more time.

Liferay 4.3 — Liferay is an open source Portal product. I have a healthy dose of skepticism towards Portal products brought about by a few bad project experiences. Liferay was easy to install and get going, it comes bundled with Tomcat and runs on HSQLDB by default. Liferay comes with a lot of collaboration Portlets like wikis, forums, news, document sharing and calendars out of the box although I get the feeling that they are all quite basic. For example, the wiki Portlet is very simple and lacks a lot of the features that one would expect in a fully fledged wiki product like Confluence. A core feature of any Portal product is the ability for each user to create their own mash-up of Portlets and Liferay supports that well. I found the administration Portlets to be slow and hard to navigate around. Overall I was impressed with the breadth of Liferay but not so much with the depth. I abandoned it as an option, mostly because it’s feature rich in all the wrong places and a general belief that Portals are evil.

In the end I chose OpenCms as “the simplest thing that works” and spent 2.5 days spiking an Intranet on it. In that time I was able build:

• A branded intranet
• News page
• Job board
• General web content pages
• Document attachments
• A tree view of documents
• Integration to a Java based forum through an iframe
• Some rich ajaxy pages using Ext JS

Brittle Selenium test suites are a common problem for projects with a significant number of acceptance tests. In the past, Selenese made it really hard to write well factored Selenium tests. The best one could do was write Selenium tests in JSPs and use JSP includes to avoid repetition of command chains (e.g. include Login.jsp).

Selenium RC gives us the ability to leverage the richness of the language to write well factored tests. One pattern that can help here is Page Models. These are essentially an abstraction of the pages in the application using classes. Taking Google as a sample application, we could write simple page models for the home and search results pages.

The page models provide access to page elements and are linked through navigation actions. We can use the page models to write tests that are more intentional and don’t interact with Selenium directly.

For more than one test class we would probably go a bit further and move the setUp and tearDown methods to a common parent or utility class. We could even make the page models reference the Selenium object directly rather than passing it around all the time.

With this approach the application and page models can be changed freely without having an impact on individual tests.

This article on InfoQ summarises the way I feel about code reuse.

I’ve worked for a few organisations that have fallen for the code reuse trap. It goes something like this. A smart bunch of well meaning developers write an application. Along their travels, they realise that some of the code they are writing is generic enough to be of use to other projects and thus the common.jar is born (or worse yet, framework.jar). The package ends up being a bucket for common services (e.g. EmailService, AuthenticationService), base classes (e.g. AbstractDomainObject, BaseHibernateDAO), utility classes (e.g. StringUtils, FileUtils) and configuration (e.g. log4j.properties). The project finishes and everyone is happy about having created some reusable code.

Sometime later, along comes another bunch of developers to work on the next great killer application. They notice all the great work done by the first bunch and go about importing common.jar into their project. However, they soon realise that EmailService is missing some features that they need, AbstractHibernateDAO doesn’t work with the new version of Hibernate, etc. So they go about enhancing and adding to common.jar, while carefully managing the dependencies on the first application to make sure they haven’t accientally broken it.

Several months, years and projects later common.jar has grown out of control. There are now 10 projects dependent on it. Making any change to it is a bit of a nightmare, requiring regression testing and sometimes changes to the dependent projects. If projects are running in parallel, common.jar becomes the battleground of merge conflicts. Fear grows and each project now starts avoiding changes to common.jar, which can lead to interesting hacks and workarounds.

Analysis at this point would probably show that any one of the 10 projects only uses about 10% of the capabilities provided by common.jar so the value of the reusable component has been diluted and the pain of managing the dependencies far outweigh any benefit provided by reuse.

So, be wary of code reuse. The cost of building several EmailServices pales into insignificance when compared to inefficiencies introduced by having to manage complex dependencies.

A few weeks ago I did some work for a client that is about to re-platform a public facing website written in Forte 4GL to Java. Forte itself is not the problem, as far as I can tell the technology is sound. Forte is a legacy platform that is no longer supported by Sun. The client is finding it impossible to hire people that have the required skills and want to work on Forte applications. The business wants to make some significant upgrades to the application. Sensibly, the client does not want to invest any more money into a legacy platform so they have kicked off the effort to re-platform it to Java at a considerable cost.

So far, this is an all too common story. There are legacy platforms and applications everywhere. What really surprised me is that the current application is only 4-5 years old, which tells me that Forte went from mainstream to legacy in an amazingly short time.

All this is interesting background in the context of what’s happening with Ruby at the moment. The popularity of Ruby is increasing all the time and we’re finding that corporate clients are starting to choose Ruby over Java more and more. Is this a gamble? Does anyone know where Ruby will be in 5 years time? 10 years? Will the current mob of smart people gathered around Ruby have moved on to the Next Great New Language? I can understand why CIOs are cautious of Ruby, I would be too.

One important consideration is the part played by the open source and Ruby communities. Vendor support is something that corporates traditionally appreciate, it gives them a warm fuzzy reassuring feeling. But in this case Sun bought out Forte and essentially killed it to neutralise a rival to J2EE. Thanks vendor! Ruby is not owned by anyone so the risk of it being exterminated is minimised. If Ruby dies it will be due to natural causes.

Java is an interesting case study because it managed to strike a nice balance between vendor support and a strong community. In the initial stages Sun invested a lot of effort developing, promoting and selling Java despite it’s well documented shortcomings. Sometime in the late 90’s the community around Java really took over and was responsible for making Java mainstream. Java is now owned by the community, just like Ruby.

The case for Ruby in the enterprise could certainly benefit from some vendor support. Efforts to deploy Ruby applications on accepted enterprise platforms will also be key (e.g. JRuby, IronRuby).