Lessons learned

Agile development practices work

The project was quite successful. It delivered, it worked, there were no errors after roll-out.  How is that even possible?

We were what you’d now call an agile team. We had two daily stand-up meetings, albeit informal, when the entire team had their morning and afternoon coffee. We went trough everyone’s tasks, and discussed whenever it was required. The Product Owner usually participated, but since we carpooled, we discussed everything in detail.

The scope was flexible. We had a set of required functionality for every targeted milestone, but we had quite a huge playing field on what else to put into it. We always managed to put in some eye-candy for the demos, and that pleased the sponsors.

We delivered often, when the framework was already up and running, the business development started straight away using the available functionality. If something was missing, we worked around it.

The team members knew what to do, and how to do it. If they were stuck at one point, they knew who to ask for help. When their task was ready, they found another one.

Open source can be decieving

In the solution we went for some upcoming open source software solutions. They worked, but all the problems in the project lead back to these.

Hibernate 2.0.something was the ORM layer, which was almost stable. Unfortunately when it was not, it was no use to go to the King (Gavain King, the lead developer behind Hibernate) with a problem statement, a failing test case and a proposed patch, he refused to correct the issues. So the project had to fork that version of Hibernate and patch it for itself. (NB. last time I checked a few years ago, but the very same bug still existed in much later versions)

We also had issues with JAX-RPC. Unlike JAX-WS from a few years later, this was quite a performance hog. Axis 1 was a poor implementation, and we had to take lots of manual work to update our WSDLs at releases.

Eclipse RCP and BIRT do not play well, unless they are the exact version BIRT is made for. This caused upgrade problems. Later versions of BIRT were simply too heavyweight to be used as an embeddable component. Eclipse OSGI is not very friendly with WebStart distribution.

These version dependencies were very heavily built in the core of the framework. So even though it could still be running, the core libraries are extremely obsolete now and I have serious doubts, that anyone spent time to upgrade those since.

Design for extensibility

It was one of my earliest projects, where I designed the architecture of a complex system alone, and that architecture was implemented as intended.

Since the layers of the application were so well defined, it was really easily extensible. Later, when there was a less busy period in my work, it took me two days, to add a web interface, that worked exactly like the client. It was a bit crude, and it was missing some features, but it was usable just as well as the rich client. Why it never made it in production? The rich client used less memory, than Internet Explorer.

Use patterns

Patterns are simple, once you understand one, you can use it, no matter what technology is used to implement it.

I’ve used the same WebStart/RichClient/WebService architecture pattern to put together two similar projects since.  First for small developments at IBM, and it was used for at least two small projects. This used Swing instead of RCP and used non-generic web-services.

The other at my own company a few years later, that was used to implement a distributed inventory system. This later one is still in use today, and uses RCP but with proper JEE 6 backend (JPA2, JAX-WS) and non-generic web services. This also has a JSF2 based web interface to complement the client.