Here at Laszlo Studios, we just picked Atlassian Jira to use for bug tracking. I'm a little disappointed because I'm actually a big fan of Bugzilla. I think it's a rare example of a web application that does just what it needs to do and no more. Unfortunately for us, Bugzilla doesn't really handle cross-project permissions. Our group has the somewhat unique requirement that we want to be able to see our bugs in aggregate, but we need to make sure our customers can't see each others' projects, let alone their bugs.

A fairly exhaustive search of the jillion bug tracking options out there led us to Jira. I couldn't find another web-based system that had that capability, and Jira had the added benefit of already being the system of choice for the OpenLaszlo project.

Before I cut loose here, let me just say that I have nothing against the good people at Atlassian. Their product does a decent job, and I have no doubt that it is very robust and enterprise-ready.

That said, I despise the UI.

Now there are plenty of examples of bad user-interface out there, but I'm picking on Jira because it's -- well -- it's just so Java-y. Here's a good example: the whole reason I bought the product is so that I can add a user and then just give her access to a certain project. Ideally, the UI would work something like this:

1. Add the project
2. Add the user
3. Drag the user onto the project

That's not how it works. Instead this is the process:

1. Add the project
2. Add the user
3. Go to the "Permissions Schemes" screen
4. Create a new permission scheme with a name like "Permissions for project X"
5. Try to add the user to the scheme and realize that you can only add groups to a scheme
6. Create a new group which contains the new user
7. Add the user to the group
8. Go back to the permissions screen and add the group to the permissions scheme
9. Go back to the project and set the permissions for the project to the new scheme

The funny thing about this process is: you can totally imagine the UML class diagram that led to it. Sure, the relationships are well specified, and I bet that different people could work concurrently on the "Permission Scheme" class and the "User Group" class, but I think that shows in the UI.

What's interesting here is that in fact this is a feature that no one else has. Presumably some product manager somewhere wrote a bullet point like:

• Configurable permissions

but then that got turned into this twisted process that was so complicated that I literally recorded it on our intranet so I wouldn't keep forgetting how to do it.

My point here is that I'm becoming more and more skeptical of the whole Java approach as a sound software engineering practice. The object-ification of everything leads to an atomic user interface, as evidenced by the separate screens for everything in Jira. That's no accident: objects make it easier to process updates and changes independently, but an architecture with a lot of objects is inherently harder to coordinate into a seamless flow.

Similarly, Java's extreme rigidity with regard to type shows up directly in the user interface. Why can't you just add a user to a permissions scheme? My guess is: because Java doesn't support multiple inheritance. Now I'm sure it's not quite that simple, but implementing a Java interface is a pain in the neck, and Java isn't quite flexible to make it so that a User is subclass of a Group (or vice-versa.)

But the real thing that shows through here is the ridiculous over-engineering that appears to be a pervasive Java "best practice." I'd rather see a product ship without groups and separate permission schemes but that has a simple and understandable model of adding a user to project. The problem with overdoing architecture and engineering is that they lead to baroque products whose features are so hard to access that those features might as well not exist. I think the unit-test heavy, extremely siloed approach to development leads to sub-par, inflexible products. I'm a scripty guy, but I just think that short, readable code that allows a little bit of flexibility is, in the end, more maintainable than a rigidly defined network of nearly standalone components.

I guess this is the essence of Java: instead of small, self-contained programs, Java apps assemble a 20 layer deep mystery cake that piles package on top of package, each making up for the deficiencies of the last. I suppose that if each of those packages were engineered perfectly, and there were no uncaught exceptions or missing entry points, then there'd be no harm in this. But this is the real world, and in a lot of ways the whole point of Java is to make it so that a bunch of mediocre programmers can get together and write reams of uninspired code that, in aggregate, does something only marginally useful.

I have really come to prefer environments like JavaScript and even PHP, where simple constructs can be implemented simply. It's a little harder to create reusable code, but it's much easier to reimplement a familiar idea for the specific purposes of a given application.

I'm a bit of megalomaniac, but I'll take my bugs over someone else's any day of the week.