RSS

Future Proof… what is it, and or, does it exist?

12 Aug

Look into the crystal ball of tech

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?

Mike

More to come…

Advertisements
 
6 Comments

Posted by on August 12, 2011 in Opinion, Technology

 

Tags: , , ,

6 responses to “Future Proof… what is it, and or, does it exist?

  1. Rich Grunenwald

    August 12, 2011 at 2:45 pm

    Mike,

    I had to smile when I read this even as a relatively non-technical person. In the sales world in which I live, “new is better, old is bad” is a common pitch, to the point that technicians and architects begin to accept it as fact.

    The reality is that so many of the development tools, hardware, software, and techniques that have been created during the past 25 or so years are quite usable for most organizations. “Technical obsolescence” is an oversold term that plays on the fears of decision makers, when in fact, many of the tools are still quite appropriate from a tactical, functional perspective.

    This is not to ignore the evolution of technology. Rather, it is to recognize and appreciate the decision points where the strategic need to adopt new technology outweighs the tactical functionality of the current platform.

    Sadly, the strategic and tactical is often confused. Heck, look at our Congress!

    Rich Grunenwald
    Managing Director
    Experis

     
  2. Michael Thuma

    August 13, 2011 at 2:27 pm

    Mike,

    Future proof is a design that allows to address future requirements and considering an estimated ‘product’ or applications life ends a lot later in practice. If the design considers to exchange parts independently this can help and allows a smooth migration and open the possibility to extend the life-cycle.

    Rich G. is right,

     
    • techmana

      August 13, 2011 at 3:18 pm

      Michael, I’m all for independent plug-able design which allows various plug-ins to be removed and updated as needed without killing the rest of the system, that is just good design and I try to always approach apps that way. However, thinking that a product can be “future proof” is just not valid. I think you can plan to work in the future but to take advantage of the future before it happens without you having to modify something.

      Taking my example of JBuilder 2006, the web designer and .war generator were really two independent pieces and I could update them so that they would work with the latest Tomcat 7.0.19, however unless you know something I don’t, there would have been no way for the developers back in 2004/5 (developed in 2004 and released in 2005) to know and support the future as it stands today. The best they could do was to design the system where those parts could be updated and they did, and those parts could be updated. But when I think “future proof” I think I don’t need to make changes or have the expense of changes in the future because I’m already ready for future.

      So in essence if they did waste time on those “future” features it would have been a total waste of time, resources, and product, because once the specification was released it needed to be updated to support the specification.

      Sorry Rich G. is wrong! 😉

      Mike

       
  3. Michael Thuma

    August 14, 2011 at 5:17 am

    Oh, this was a copy paste thing …

    Rich G. is right – >>In the sales world in which I live, “new is better, old is bad” is a common pitch, to the point that technicians and architects begin to accept it as fact. <>but to take advantage of the future before it happens without you having to modify something.
    This is impossible. The best a customer can get is that a solution can be found. Agreed.

    I don’t talk about tools, … they are simply troublesome already on a mid-term.

     
    • Michael Thuma

      August 14, 2011 at 5:19 am

      Sry, formatting did not work correct.

       
  4. Angelo Serra

    August 18, 2011 at 7:36 am

    I don’t believe there will be such a thing as until the underlying pieces (OS, APIs, frameworks) become extremely stable. At the point the OS changes, or a framework changes, certain things either get deprecated or cease to function at all. While there is certainly some validity in some tools or OSes working for companies for an extended period of time, I would hazard a guess that those software products are relatively “close to the metal” for the most part and/or do not rely on any significant number of integrated components.

    Currently, I have a system facing a complete upgrade – db, db server, app server, web server, reporting server, multiple OSes and JDK – due to a cascading issue. I have one vendor refusing to support a product they sold any further – they are attempting to force us to move to a more recent version of their product. If we run into any issues, all level of support say the same thing, “upgrade and then we can help you”. Of course, upgrading that one piece forces an upgrade on the other pieces due to inter-dependencies. Of course, this is a relative small system – we only have about 5M LOC, 750Gb database, and perform a little over 3M transactions per day and a little over 1M web pages served per day.

    I would contrast this to building something along the lines of a chair. I would argue that a windsor chair has been the same for going on 400 years. Future proof? Absolutely! People can still use one of these beauties the same way it was used when first created. If it fails (wood rots, broken through mis-use, etc.) another can be created using the exact same methods and tools.

     

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: