In one of my prior posts (http://wp.me/p1IX3y-I) I wanted to try the latest and greatest JDK from Oracle, 7.0 using JBuilder 2006Enterprise. What made it interesting is that JBuilder 2006 was written with JDK 1.5 (5.0) and was released back in 2005.
One of the discussions that I was part of at one of my old companies was the idea or concept behind “future proof frameworks.” The conversation would be related to IDEs and Java and it would work something like the following:
Tech person: We need to move from established IDE/platform (proprietary) because the current one (internal) is way behind.
Me: Behind, how?
Tech person: It does not support this or that, or its framework is old. Only the new platform (open source) will be future proof and not have the issues that the current one has.
Me: Those issues could be resolved with a little more investment or a change in priority of what needs to happen next.
Tech person: We spend too much money on the underlying framework. If we move to the new framework, we won’t have that investment?
Me: You mean we won’t have the investment in the older framework but we will still have the investment to modify the plug-ins when the framework is updated or modified… so it is the same thing, just one is working on the established in-house framework and one is investment in the new framework.
Tech person: No, the new framework is future proof, you won’t have those types of things, and those people now working on the original stuff can be put on to new features and plug-ins to help add more functionality.
See you don’t understand future proof. Since the new framework will have that approach, the needed continual investment into making the underlying framework work, will not be needed.
Me: It’s the same thing; we will have to put money into the framework interfaces to support our plug-ins and any other plug-ins we include. Because we have to ensure that any plug-ins from the wild will not interfere with our in-house created plug-ins. So, we will still have to make changes if any plug-in interference is found.
Tech person: Again, you don’t understand. Since the new platform is future proof and the plug-ins are based on that platform, they are also future proof, so the amount of overhead or work will be very minimal because the plug-ins are again, future proof.
Needless to say, this type of conversation went on, and on, and on, and on… and I never won the argument. However, I was somewhat vindicated that the new framework, which was supposed to be future proof, turned out to be like every other program in history. It would need adjustments as time went on and the amount of resources to build, maintain, and deliver the product ended up being around the same cost, if not a little more.
After doing my little experiment with JBuilder 2006, I had to smile to myself, as JBuilder was able to handle most of the new Java without any changes. Were there issues? Heck yeah, but the fact that the product could still do most of the functionality it was originally designed to do was a great “tip of the hat” to the great engineers and quality assurance people who created and delivered that product.
In a more recent issue,Delphimay be too future proof! During my time at Borland/Inprise/Borland/CodeGear/Embarcadero, we would have customers still using older versions of Delphi and C++Builder, they would not move. The product was still producing working code and they understood the limitations of these old products very well, and did not want to change.
Now Vista and Windows 7 are starting to make these customers move to the newer products because the underlying OS is starting to change how it handles things. Keep in mind thatDelphi5 was released in August 1995, so that was a great product that was very future proof, in a sense. Most of these developers were still using the older Windows OS(s) and the need was not that pressing.
For me, the great thing about computers and software are that they don’t stand still, they are always evolving, and so they support the future when the future comes. Having an application or product work in the future when things are different is fine, but most likely that product is not going to support the future, it is only going to work in the future… a much different thing when I think of future proof.
I mean, I was happy that the JDK worked in JBuilder 2006, but JBuilder did not know of the changes in Java and how to best support those features. As I stated, things like the latest Tomcat 7.0.19 was outside the realm of JBuilder 2006, 6 years ago, and there would have been no way for JBuilder to support the web changes defined by the later specifications of Servlets, JSPs, and the like. So, while it again worked… it was a hollow victory in the sense that additional work would need to be done to make it truly support the Java of today. But, that would be true for any product that was written before the latest and greatest updates were released.
So what are your thoughts on the concept of future proof? Is there such a thing?
More to come…