Annotations or XML

I just commented on a post at stackoverflow asking for suggestions of criteria which should be used to compare the annotation or xml approach when configuring classes for hibernate or spring. Saying then that a decision will be reached on which one is "better".

I responded to the post and you can see it here.

While an interesting academic exercise, I don't foresee it having any real value. The decision on whether to go annotations or xml is made solely on a case by case basis.

But then I asked myself, what are the conditions under which xml/annotations are used with reference to configuring spring beans.

I was on a project where we had hundreds of beans - we were working under Java 1.4 so could not use annotations. We went so far as to use xdoclet where you add the annotation information as javadoc tags in an attempt to account for this constraint. It wasn't ideal as you have to generate the xml from the source code and thus the xml can easily be out of sync - don't have to do that when using annotations.

So in that context, annotations won, and to my mind, for many "workhorse" beans it's a no brainer. Maintaining the xml for hundreds of beans where no custom configuration is required, annotations is definitely better. Annotations handle refactoring, method name changes, classname changes, even certain structural changes require no adjustment to the annotations.

So is xml now defunct, have annotations killed the xml star?

No - there are two contexts where I am essentially forced to use xml.

1. Where I want to customise configuration.

So I want to be able to specify different values for beans, or if I want to change the bean I'm injecting into another bean. I want to be able change property values. Doing this with annotations though possible would be too unwieldy. While it's possible to run Windows Vista, that doesn't make it a good idea.

2. Where I don't have access to the source code of the classes I want to create as beans i.e. where I want to re-use classes from other libraries.

Because I don't have access to the source code and/or I want to potentially create more than one bean from the same class, xml is the preferred approach here. The key difference between xml and annotations it that when using annotations I do not have to specify the details of the class, i.e. I do not have to contextualise the information I'm adding, it is already contextualised because it is connected with a class, field or method. With xml I always have to add this contextualising information.

In my current project I have a small xml file which has all the beans created from re-usable components in it, and that's all. Everything else is done via annotations.

That's how it should be?

If I had R10 or a dollar, for the amount of times developers assume something because they say it "should" be like that, I would be rich.

I must admit, I find it a bit weird that they assume things because it is how it "should" be as if the computer is morally obliged to be like that. We say things like "It should rain tomorrow" or "You should not steal"... implying either that there is some uncertainty to the statement or that it is a recommended thing to do.

Notice that with the use of "should" there is NO certainty - why I find it strange that developers even use the word "should" with reference to code. Developers should only be talking in absolutes when talking about code behaviour, and until they can talk in absolutes they should keep their mouth shut.

After all, they have the code in front of them; they can look at it - if it's a spec they're looking at, yes, the behaviour specified in the spec "should" (correct use) be what the code does. That is how things are setup, but if you have the code in front of you, I don't want to hear "should". Why take the risk of the "should".

Just today this is what happened. A method was taking a string and the string was called "status". Now there is also an Enum called "status", and the developer figured well, that "status" and the enum status should both have the same "toString". iow, the toString of the enum should map to the valid strings that the method understands... a big should. If that is the case then why does the method not take an enum.

Now, yes, it should be like that, but is it? In this context I'm not interested in should. This shouldn't cause a bug is just not good enough.

A cursory glance at the code should, oh sorry, can, often lead to the resolution of the doubt, and in this case, the assumption was proved wrong, causing a time wasting bug.

So in a development environment when one is asking how is the code behaving, one should never hear "should".

Urgent or Important?

Recently I had spent some time working at a new client (old client for my company, new client for me). I spent 3 weeks there getting familiar with the environment and am now working off site.

I was struck by how "busy" the place was. There were people on the phone constantly, thousands of mails flying around, the project is way behind schedule, the environment is a little mad, maybe chaotic would be a bit strong to say, but it is on its way there.

It just does not seem as if a lot of though and critical, deep and creative thinking has been brought to bear on the project. People are just going from one crisis to the next, doing what is urgent all the time and failing to address what is important. Either they don't have time, or they deem what is urgent to be important and can't really tell the difference!

What is interesting however, is that from the client's perspective, lots of things are happening. People are doing things, working hard, appearing very busy - but not necessarily getting things done.

Contrast that with an environment that is calm, smooth and running as planned. How would that look? A little boring in comparison. People would not appear busy at all. They'll be sitting at their desks working, not talking to much on the phone, not be stressed, and have everything under control. The client may interpret this as being lazy and not working, because we certainly don't appear so busy.

Netbeans - a first really serious look

I have just started seriously using Netbeans for the first time - I've been forced to because it's what the client uses.

And I have to admit, that having used Eclipse up till now, I am definitely not enamoured with netbeans at all. In fact it has done nothing to recommend it. I constantly find myself going... oh, I wish I was using Eclipse.

Netbeans fans might be crying foul right now... and they have a right to, let me record some of my initial frustrations...

1. No inline variable
2. No inline method (though there is an extract method, called introduce method).
3. When you use the template short cuts (for, create field etc) the tab does not leave you where you want it to
4. It hides a lot - we're doing web service development - all the ant xml files which are used to compile and build, you don't see.
5. No call hierarchy
6. Search facility is nowhere near Eclipse
7. No Quick diff comparing repo version with local version (via the ruler)

A good way to explain netbeans is to say it is opinionated software (I remember someone describing ruby on rails like that) - iow, it's great, if you obey the rules and if you want to stay within the confines of what it wants. I don't like the ant scripts it generates and uses to build - I want to roll my own, as eclipse will let me and thus customise them the way I want to.

So what do I like about Netbeans?

It has very strong integration with glassfish - tells you a lot about the running glassfish server you're using to deploy to. I also wish I could use the collaboration stuff, because I've seen that it is very good.

I'm going to have to continue using netbeans so I'll see if my opinion changes... I'll wait and see.

Why don't people understand the computer?

I am always fascinated when I observe people using a computer's user interface, even when using the user interface of the popular video game, guitar hero.

I have played guitar hero with a lot of "normal" (non computer) people and have found it interesting to observe their interactions with it. This process has enlightened something else I have been spending a lot of time thinking about, and that is why people cannot understand/use a computer.

And Guitar Hero is a good example. Even something as (I think) simple as the user interface of guitar hero causes people to go... I don't know what's going on, I can't use this. From my point of view, it could not be simpler, everything is self explanatory and right before you. It gives you all the feed back and guidance you need to quickly navigate around - and I therefore cannot at all, understand why they find it so difficult - I just can't get into their head and understand.

Until now when I finally understand why they find it so difficult.

For these people, the user interface of guitar hero might as well be Chinese - that would be just as comprehensible to them! I understand the language of the computer - they don't, and it is a question of language. They don't speak "computer", or should I say "read computer" since the "computer" language is only a read language. You can definitely get different abilities in this "computer" language - the people I'm referring to here though have no clue. And so it makes sense that people can be "computer literate", able to read computer - it's a very appropriate label for someone who knows their way around the computer.

The conclusion to all this is that whereas before I could not understand why people cannot understand the simplest of interfaces, and these people are not uneducated, now I fully understand why they cannot operate the interface. They need to understand the language it's communicating in.

Development On a VM - who needs a desktop?

Recently, in our dev shop, we have taken delivery of a rather high end server class machine. We installed linux on it and VMWare. It is, needless to say, way faster than any of our desktops.

We created a VM, installed ubuntu on it and then added that as a hudson slave. With that VM, the time for the simple compile job is down to 13 seconds from 45 seconds (gives you an idea of how fast it is).

We created another VM with ubuntu and I started tinkering around on that VM. I installed eclipse on there and started using it for my development by exporting the desktop to my workstation. The remote desktop equivalent in VMWare is very good - more than adequate responsiveness etc. My personal laptop/desktop is now just being used as a dumb terminal...

The advantages of developing this way:

1. Hardware upgrade costs are significantly reduced - don't upgrade your developers hardware when next upgrade cycle starts - let them keep their current hardware (and use it as a terminal) and give them a VM to develop on.
   
2. Maximum value is extracted from available hardware - I reckon we could put about 4/5 developers on our new server, depending on size of applications being worked on. This will mean that the server hardware will be very well exercised, a lot less wasted CPU cycles
3. Configuration and down time are almost non existent - new developer arrives, just provision a new VM from the image and he's up and running. Developer's image gets corrupted, same solution.
4. Significant cost reduction - because economies of scale can be leveraged, and hardware is better utilised, hardware costs are significantly reduced.

The only disadvantage of this solution is the lack of mobility - you need to be within a fairly fast network of your beefy server for this to work, let's hope that line speeds can be made fast enough to handle this.

For dev shops which issue laptops is less of a solution, but if you have a location full of desktops, don't upgrade them, just use them as dumb terminals and virtualise their requirements.

Evolving an Architecture

So, when last did someone ask you about apiece of architecture, they asked, how are we doing to do this? And at stage you, the architect, or involved in the architecture, weren't quite sure. Not because you're a bad architect, but because you don't have enough of an idea of what is required at that stage, and because right now, that issue is not front and centre. In other words, it hasn't had the full treatment. You're currently sorting another issue and will get to that. Right now, the solution employed in the area asked about is "good enough". Probably not going to go into production like that, i.e. it needs work, but for the rest of the project to continue, it's adequate.

I don't know how many times I've found myself defending an architectural construct in this manner. Yes, I'm aware of the issue and will address it. Furthermore I am forever finding myself changing the way things are.

An architecture of a system must be a fluid thing. It is something which evolves. As the designer you should always be willing to modify something because it has not met it's requirements and/or you, or somebody else has come up with something better. One of the characteristics of a good architect is that they are willing to take risks, change something for the better even though it might negatively affect the application in the short term. Developers for example, might not like what you've done, but if you've done it for the right reason's they will see those reasonsand buy into the change.

You will not get everything right at the start, accept that, choose what is important to get right now, defer the rest, but make sure you get to the rest. When developers ask you about the "rest", let them know why it is that way, and that you're going to get to that issue. Often I've felt indignant at these kind of question, that ask about the "holes"... but I shouldn't be, it gives me an opportunity to give them a greater understanding of the system, and an opportunity to gain an ally. I suppose however, the ultimate is for developers to see where those defferred issues are and to know intuitively that they will be addressed.