While the advantages of annotating the code (JSR 175 - Metadata Facility for Java) are somewhat clear to me, I have been wondering what the drawbacks could be. I don't deny that being able to specify auxiliary information for classes, interfaces, fields and methods is a good thing. What I question is the means we will supposedly use to achieve this, namely, we will be putting the whole stuff directly within the code. If not used with care, annotations could (and most certainly will) massively contribute to code pollution as legitimately pointed out in James Strachan's web log this morning.

James also mentions that future IDEs should be made more clever and handle most of these boring details for us. For the most geekish of us, I can also imagine a functionality where we can define the granularity of the details we want to see in the code and then use some sort of slider control to zoom in/out the code details. Yesterday, the Eclipse community announced that code folding has been added to their IDE. Great!! I see this as a first step towards removing visual clutter in a selective and temporary way. Although, much more will have to be done in order to allow developers to use their eye power more efficiently.

Actually, the problematic is quite simple: we want to get rid of the many different documents that describe some aspects (not necessarly meant in the AOP sense) of the same concepts and put everything together at one central place, namely in the code. That way, it seems to be less likely that we forget something when we have to do some changes. While this is questionable, I don't doubt in the expressive power of annotations. What I fear is that this expressiveness could be used (inadvertantly) in a way that ends up not being beneficial to developers, thus defeating one of the primary goals it way initially intended to attain.

This pretty much goes in the same direction as mentioned in my previous blog, namely that current tools will have to be considerably improved to successfully address problems such as this one in the future.

"How will we develop software in 50 years from now?" As a passionated developer, this is one of the questions that often crosses the maze of my neuronal highway. I think this question is more than legitimate given the ever-increasing complexity of the tasks that have to be carried out by software systems and the pace at which new technologies are created.

I have a very personal opinion on this problematic which I have shared with some close friends and coworkers of mine. Personally, I think that the way we are creating software today is doomed to failure. Don't get me wrong, I'm a passionated developer, I love coding, I could spend my whole days and nights on coding new software.

It's just that I don't see current practices going anywhere mainly because of the complexity we are asked to handle. Of course, some of you will argue that if the software is architected and designed correctly (whatever that means), the complexity would be kept to a minimum. Basically, if complexity shows up, there must be a problem with your design. I don't agree with that since I'm of the opinion that the complexity lies in the problem at hand and it is neither removable nor negligible.

My opinion is that today we dramatically lack tool support not only for dealing with this complexity but also for tracking it down into the software that realizes one solution of the problem. A project usually involves an heterogeneous group of stakeholders (analysts, developers, architects, marketers, project managers, end users, HR, etc) who all have different interests in the project. How do we measure the impact of change if one or more of those stakeholders change their mind during the project? (Every sensible person knows that changes do happen!! A lot and often!!) How can we discover where and how the software will be impacted by the changes? Even if we do know where to make the changes, how do we know that we have applied them consistently across the whole software? Even if we apply them consistently, how do we know that we haven't forgotten to change some other code that is related to the code that has just been updated? As we have seen yesterday, MDA is supposed to partly solve this problem, but this is not going to happen anytime soon. It won't hurt to keep an eye opened, though :)

Some of you will argue that XP best practices and agile processes are already taking care of this. Well, in a certain sense they are, but I dare you to find one single tool that includes and automates these practices. In the future, we will have to come up with smart tools that somehow "participate" in the development process and proactively assist all the project stakeholders. In the future, we won't need passive code editors and/or modelers anymore. What's more, since the project stakeholders all come from different places in the company (or even from other organizations), we will need tools that can share all the digital resources of a project in a much better way than CVS does today.

I'm having a nice discussion on Javaranch.com about this. Agreed, this is no pic-nic, but I can assure you that it will be a fun ride :)