Sunday, May 28, 2006

Billion Dollar Boondoggle

The "Canadian Firearms Program" more widely known as the "Canadian Gun Registry" was a program instituted by the former Liberal government of Canada under Prime Minister Jean Chretian to license and register certain types of firearms across Canada. Bill C-68 was introduced in February 1995 and has been controversial ever since for a number of reasons but undoubtedly the issue that has caught everyone's attention has been the cost of the program, now over $1,000,000,000, and growing.

So leaving the politics behind, I was interested in the technical details behind this program from a software developer's perspective. What exactly did these guys do wrong that would result in such astronomical cost overruns? What technologies did they use and what could be learned from their mistakes?

Well it was surprisingly difficult to find information but finally I came upon a two-year-old article in eWeek titled "Canada Firearms: Armed Robbery". The system was originally comprised of an Oracle 7 database and a PowerBuilder application built by EDS. Given what I know about those technologies, I doubt that the problem was the technology. Instead, it appears that the biggest problem was incorrect initial assumptions and ballooning, ever-changing requirements.

But after eight years of mismanagement what was the solution? That's right! They decided to rebuild the application with a different set of technology and consulting resources (CGI)! Maybe the implementation really was poor, but I suspect some incompetent management types were deftly pointing fingers elsewhere and some unwitting bureaucrat believed them. Ahhh that old story...

Tuesday, May 23, 2006

DAOs and ORMs

The discussion that this article on the ServerSide generated reminds me of an article I wrote a little while ago. The original poster gets a bit confused about the problem because he assume the use of an ORM means that you need to use the "Open Session In View" pattern. But if you get by that and read some of the comments, you discover that many people (like me) don't believe that the DAO pattern is necessary when using an ORM solution.

A valid concern about ditching DAOs is the coupling that may happen between your domain objects and your persistence mechanism. But if you like ActiveRecord or Rich Domain Models or Annotations or XDoclet then you've already made the choice of productivity over ultimate framework plugability and should just get over it.

But if the coupling is still nagging you and you're concerned about sprinkling framework API calls throughout your code then maybe you want to consider looking at EJB3. Instead of using the vendor's API (e.g., Hibernate, Toplink, etc.) you can reference standard annotations and classes that are free of implementation specifics. At least that way you've provided some hope of switching out implementations.

In the end, question why you're using the DAO pattern and then ask yourself if you've already done something in your code that has violated that pattern. Think about your use of OpenSessionInView filters or the navigation of lazily instantiated collections in your view layer. Maybe DAO and ORM really don't mix...

Saturday, May 13, 2006

XML Glue


When I discovered XDoclet I quickly stopped editing my hibernate mapping documents by hand. From the XDoclet website:

XDoclet lets you apply Continuous Integration in component-oriented development. Developers should concentrate their editing work on only one Java source file per component.

This approach has several benefits:

  1. You don't have to worry about out dating deployment meta-data whenever you touch the code. The deployment meta-data is continuously integrated.
  2. Working with only one file per component gives you a better overview of what you're doing. If your component consists of several files, it's easy to lose track. If you have ever written an Enterprise Java Bean, you know what we mean. A single EJB can typically consists of 7 or more files. With XDoclet you only maintain one of them, and the rest is generated.
  3. You dramatically reduce development time, and can concentrate on business logic, while XDoclet generates 85% of the code for you.
But unfortunately I still find myself editing a ridiculous amount of Spring XML by hand. Spring sounds nice in theory but after using it for awhile I don't think there's anything wrong with the factory and singleton patterns. This unholy quest for ultimate flexbility by gluing components together with XML has to stop. Most of the time you simply don't need it.