Improving the Java Specification Request Process

The JSR process is know to take a lot of time produce an actual specification. On top of that, it often produce overly complex specifications that are way too overkill to solve the problems they intend to solve. It is also a process that is driven by the main vendors desire with little thoughts for developers.

We could probably shorten the process and increase the usefulness of JSR by bringing a bit more agility in the process. Here is what I think we could do to make things a bit better :

1. Create the reference implementation first. Then produce the specification. A working implementation offer greater value than just having a specification. It allows the community to use it and comment on real life issue. This is way better than commenting on a theoretical document.
   Groovy is a good example of creating a reference implementation before a specification. Granted, it took a lot of time (lack of resource availability) to achieve, but in the end, we have a better Groovy than if we produced a specification first and then implemented it. Once a specification is voted, there is little coming back (beside repeating the complete JSR process). Voting on a working implementation mean voting on the real thing!
   
2. Make the sponsors of the JSR provide full time resources to work on the reference implementation. There is nothing worse than only having resources working part time on a JSR. Things go slower and communication suffer when the team members have other responsibilities.
3. Make the reference implementation Open Source from day 1. Make the code public as soon as basic functionality is built in. This allow the community to participate early and provide early comments.
4. Make all communication related to the JSR public from day 1. Public forum and/or mailing list increase the diffusion of the information. Issue/feature tracking should be readily available and every decision made on issues/features should be made public. Having public communication will again increase the community involvement and at the same time decrease the sentiment that the JSR driven by the vendors secret agenda.
   
5. Have the JSR team produce workable software at regular intervals (every months for example). These content of each iteration should be determined at the beginning of the iteration based on the issue/feature backlog. Each iteration should have a specific goal to make sure that the team focus on the right thing for the iteration.
6. If the JSR address something that is already available in an Open Source project, it should review the project and base it's work on it. If something exists there is no reason to start from scratch.

Doing all of this will ensure that at even if the JSR is voted off,the community will gain working software. It will then be its choice to use it or not. But I believe that with these kind of changes, most JSR, will either fail early (which is good as less time will be spent on it) or either succeed when they attain the voting stage (aka version 1.0).

iPhone

Apple finally announced the much rumored iPhone . The device really look nice and follow the thin is in concept launched by Motorola .

What's being announced is really cool. But I wonder about what's not being announced :

• Java support : not a word on that. Granted, it run OS/X and Widgets but most phone today ships with Java. It certainly has the power to run Java,
• What kind of CPU in inside this thing. If it runs OS/X it may be an Intel or a PowerPC... XScale like many other devices uses a different instruction set than Intel Pentium CPU AFAIK. So will I be able to run any OS/X applications? Guess not. No word on CPU speed either,
• How much memory (beside storage which will be 4G or 8G)?

I also guess that the various sensors that are in the device will eventually have more uses that just dimming the screen, detecting rotation, etc. Will they be easily accessible by application developers?

I guess we will have to wait until this summer to get more details.

One last thing! Which carrier will they choose for Canada? The device is GSM which mean the only choices are Fido and Rogers (which are just two brand for the same carrier). Most of the time Rogers has the coolest phones, but I hope it will also be available on Fido.

Anyway at 499USD, I cannot say that's it's cheap. But it does seems to be a nicely done convergence device.


UPDATED: I forgot to talk about GPS functionality. Adding this would make it the ultimate convergence device. Maybe they'll announce that next year!

It is also kind of funny that they waited for the iPhone to put Bluetooth in their iPods.

It's NOT the code NOR the process, stupid!

It looks like some people think that focusing on a process and having a high level view will yield more successful projects.

I have to disagree with this statement. While a process may be a good thing, in most cases the process is the cause of failure. The reason is simple, processes are often put in place for one reason. To reduce the per resource cost. It seems that executive believes that having a process will allow them to hire less skilled individuals (this really mean cheaper) and to still be able to deliver a project on time and on budget. Since the birth of software development, we have people who champion processes to executives to reduce their costs and increase the rate of success. They will often use the quality argument to support their point of view. However, even if more people use processes, the rate of successful software projects has not increased throwout the years nor the cost has decreased.

I have yet to see a project that is so trivial that it will succeed with unskilled people using a well defined process. Choosing the appropriate technology, creating an appropriate architecture and design are no trivial tasks. No process will ever make these task easier to do or more predictive. Only having the right people for the task will increase the chance of success. A process can help them, but never will replace them.

Focusing on code or focusing on processes are both wrong. Get good people on your team and focus on what really matter... What needs to be delivered! Focus on what is going to add value for the client/user. A working application will give more value than a well defined process. A process can help in achieving this as long as it's a mean but not an end.



It's NOT the code NOR the process, stupid! It's the right people focusing on the appropriate objectives!

More 2007 Predictions

My significant other just told me that I just made prediction only for Java and Ruby. That with the 2007 Predictions title, I shouldn't have such a narrow field of predictions. So here are more predictions :-)

Strong weather all over the world

2006 was relatively calm weather wise. With the global warming having more and more impact on our environment, I predict that 2007 will break every record in extraordinary weather related events.

War in many parts of the world

War is going (continue) to rage in many parts of the world. Too many innocent will continue to die due to selfish leaders ambitions.

Civil liberties will continue to be challenged

Civil liberties in most developed countries will continue to be challenged. Mostly in the name of so-called security or war against terror. The fact is that all these actions against civil liberty reduce security and put more oil on the war against terror fire.

Love will still be in the air

Even if bad things happen to the world and it's population, love will still be a great driver in human beings. Even in horrible times (which I don't believe we are in) love always find it's way!


So this is it! More predictions!

Luv U Annie :-D

2007 Predictions

Everybody doing it! Not wanting to be left in the cold, I will follow the herd and make predictions for 2007.

RoR will run flawlessly on a Java Application Server

The good people from JRuby are making incredible progress since they've been hired by Sun. We will soon be able to run RoR applications with no (or very little and trivial) modifications on Glassfish or other Web Container. Will that makes RoR application more scalable? I'm not sure. But it will increase RoR momentum in Java shops. When you talk about RoR to a java shop, the first question they have is "Will it run on Tomcat|WebLogic|WhebSphere|...?"

JRuby will take the top spot for scripting the Java platform

To the demise of Groovy, JRuby will take the spotlight. The main reason is the previous prediction. Once you can run RoR on a Java application server, nobody will need Grails. Grails is the only use of Groovy that create adoption.... Unless some other killer Groovy application, tool or framework is created.

RoR adoption continue

That's a fairly conservative prediction. RoR as a lot of momentum.

Java 6 adoption will start slowly in Q3

While Java 6 is out. It's adoption will grow slowly and will mainly be driven the scripting language support. Java 5 had many compelling reason to get adopted by many shops, but many many many application are still running on Java 1.4. Beside scripting support, there is nothing compelling enough in Java 6 to make it's adoption within the enterprise faster that Java 5.

Something will happen in Java build tool space

A lot of people are tired of Ant . Maven is cool, but lacks flexibility. Scripting language is getting more attention... We have Gant, Raven, JRake and many other existing or yet to be created build tool that use scripting language. By the end of the year, one of them will start getting a lot of traction. My best guess for now is Raven.

Java Specification Requests will become less and less relevant

The JCP is not working very well. It's too lengthy. Design by comity does not work well. Many JSR do not stand the sand of time. Today JSR mostly reflect some existing API with less feature (JPA vs Hibernate for example). They do not offer innovation, they just tend to seal mature innovative technology in the platform. New language features takes too long to traverse the JCP and with the open sourcing of Java, it will become easier for one group to add new feature to the language and to make a Java distribution of it's own. And with JSR like JSR-277 that create more turmoil than solve any problem, more and more people loose interest and faith in the process. Sun is not even interested in really supporting existing JSRs. We have a JSR for Groovy, but Sun hire the JRuby developers without giving any resource to Groovy. That's it! I made my prediction for 2007. This is probably my last post of the year, I will try to post a bit more often next year! In the mean time, have a Great Christmas and a really Happy New Year!