Determining if language/framework/technology is 'Future-proof'

Question

I'm a PHP developer and I recently started to work with CodeIgniter. It seems that whenever I search for something related to CodeIgniter, the blog posts and what not are usually from '09 or '10, so it got me thinking, is CodeIgniter still relevant and is it going to be in the future? Is there another framework that is taking it's place?

The same goes for other languages and frameworks as well. At what point do you abandon learning certain languages or frameworks? Is there any easy way to find those that are emerging and worth picking up?

Answer 1

It's not an exact science, so don't expect to be able to predict the future trends in the technology landscape more than 5 years out with any certainty.

But I would look for all of the following:

• Installed base - a bigger installed base means lots of companies will contine to invest in the technology and its maintenance, which means developers will be needed to work with the technology. Positive cycle ensues. For example Java, like COBOL before it, is not going away for a very long time.
• Broad-based Industry support - are there multiple big name industry players backing the technology? Only one committed backer is a warning sign - it could get dropped or sidelined any time with a single change of strategy.
• Open source - major open source products have proven to be extremely good long-term bets (look at Linux, Apache, Red Hat, JBoss, Eclipse for example....). Proprietary products on the other hand are somewhat at the whim of a single vendor where you are at risk of discontinuation / ramped up prices / attempts to force to to migrate to their "next big thing".
• Quality - high quality products will simply live longer because people will want to use them rather than switch to something else. Conversely, low quality products will get abandoned as soon as something better comes along.
• Innovation - is the technology towards the cutting edge of innovation? If so, it is likely to gain adoption and support among the more innovative companies and users. This will ultimately start to become mainstream (I'd say new languages like Scala and Clojure for example are in this category)
• Community - it there a positive, open-minded, pragmatic, committed, helpful community around the technology? These are the people who will ultimately guarantee it's future.....

Answer 2

There is no way to know if something is going to be future proof I would rather focus on does the technology help me solve the problem I have today. You would abandon learning a certain language or framework when it no longer works to solve your problems.

Be involved in the community that represents what you are doing and you can get a good sense on whats coming and going but even then I would rather spend my time with the best tool for the job not whats hot or what i think will be hot a year or two from now.

Answer 3

There is no way to determine definitively whether something is future proof. The closest that you can come is to determine the level of activity around a particular language or framework - if there's a lot of developer activity, it's usually a good sign that the language/framework is trending up in popularity and will be viable for a while. The inverse indicates that there is less excitement and that support (via developer forums) may be harder to come by.

So long as your language/framework of choice solves the problem that you're trying to solve, you shouldn't need to worry about future-proofing, unless you're clearly working with a dying technology. Technology keeps changing - one thing you can do is to keep track of industry trends. Learning new programming languages/frameworks, as noted in this thread, can help you keep up with trends and gives you an opportunity to continuously evaluate new tools.

Answer 4

"Futureproof-iness" is as much about will-power and stubbornness as it is about more pragmatic concerns.

An extreme example is this. Sparkle Filters IS STILL RUNNING an IBM 402 computer from the late 40's as their accounting system. This is a machine that is programmed using electrical plug-boards rather than "files".

I personally have had experience with a company that still maintain MS-DOS based machines inside specialized instruments that are designed to operate for decades. I've even scrapped an operational PDP as late as 1997.

I'd say that if your company gets a visit from the computer history museum, like Sparkle Filters did, that would be a sign that you (or your ancestors) have successfully "future-proofed" the system!

Answer 5

I can answer whether a particular technology is future proof - the answer is almost certainly no, since you didn't put a timescale on this.

To make this question answerable you're going to need to add some more detail to the requirements. For example:

• What timescale are we talking about - 1 year, 3 years, 5+ years ?
• What would be the cost of picking something that is not around in 5 years time ?
• What benefits will you get from choosing a less "safe" option, and do the benefits outweigh the risks ?

The choice of a language/framework/technology is really a part of risk management in the project. As with all risks you'll need to consider a number of factors (I'm trying to keep this short) and then take steps to reduce it to a level appropriate to the situation in hand.

Like with most things in life, the activity that involves the lowest risk may not actually be the best choice.

In short, how much uncertainty are you prepared to live with compared to the benefits you are going to reap from using over the expected life time of the project.

The longer you want to look in to the future, the less certainty there is going to be. If you are happy with only worrying about the next 2 years for example, your choice will be far easier to make (and leave far more options open to you) than picking something that needs to be around for the next 10 years.

Answer 6

There are so many factors to this I would say its impossible. Among the things that could go wrong are:-

• Fashion. People lose interest and turn there attention to a new prettier platform. Perl had a near monopoly of web applications circa 2000. Its barely mentioned now.
• Vendors market share. circa 2000 you would have though C++/Sun Solaris was good till the year 3000.
• Corporate Shenanigans. A couple of years ago I would have choosen Java as the future proof platform. With ORACLE copyrighting the API etc. I think will will see a move away to some other language framework, I just wish I knew which one.
• End of the road. I am thinking of things like Visual Basic which after a long and honorable history just cannot be stretched any more to accommodate the latest thinking in software development.
• The loser wins. PHP (which I like) would not and never has won any beauty contests among developers, but its has emerged as the undisputed king of the web. When I first wrote some php in 2004 I would never have backed it as the linga franca of web development.
• The ugly ducklings. Javascript without changing a single piece of syntax or adding a single API, suddenly went from a hokey scripting language which animated annoying banner adds to the center piece of WEB 2.0.

In the end it doesn't matter that much. CodeIgniter works for you and delivers what you want. Nothing you do will stop working because the blog postings are old or the release rate has slowed down. So my advice would be to use what works now, and, deal with the future when it comes.

Answer 7

A PHP framework, Symfony, explained this perfectly at their site.

10 criteria for choosing the correct framework

You're making progress and that's a good thing! You already know that you are going to use a framework to develop your site or your application. But which one? Here is a checklist that you can use to avoid making a mistake:

1.Popularity and community size

The more well-known and recognized the framework is, the more it will be “living,” evolving and complete: new ideas, the number and quality of plug-ins, etc.

2.Philosophy

This is the very essence of the framework: it is a fundamental criterion for ensuring that it will meet your needs. A tool developed by professionals for their own needs will obviously meet the demands of other professionals.

3.Sustainability

Before choosing a framework, make sure that it will be able to keep up with you for the duration. This simplifies both the maintenance and upgrading of your applications.

4.Support

Another criterion that should not be overlooked is the ease of finding answers to your questions and getting help. Identify the support that is available: from the publisher. From a community (mailing lists, IRC, etc.)? From Service Companies (development, support, training)?

5.Technique

To avoid becoming trapped in a labyrinth, it is always preferable to choose an interoperable solution; one that respects best practices in terms of development (design patterns)

6.Security

Any application is potentially vulnerable. To minimize risk, it is always better to select a framework capable of ensuring security functions (XSS management, for example).

7.Documentation

It is an absolute necessity to evaluating the nature, volume and quality of existing literature about a framework: a well-documented tool is both easier to use and more upgradeable.

8.License

Licenses are important simply because they can have a significant impact on your applications. For example, an application developed using a GPL-licensed framework will necessarily be subject to GPL. On the other hand, this is not the case for an MIT-licensed framework.

9.Availability of resources on the market

Perhaps you would want to have a technical team surround you during the development phase or in the longer term, for both maintenance and upgrades. In other words, make sure that the skills required for the tool that you are using are available on the open market.

10.Try it out!

That's the key! Don't be satisfied with reading reviews, comments and rumors, good or bad, on the Internet. By testing it out, you will be able to make up your own mind and ensure that you are completely comfortable with the tool.

Answer 8

The key is patience. Patience, patience, patience. There's no way for sure to predict the future. (did I even have to write that?) But if you give the new technology a couple years and watch how its adopted you'll have a good idea of whether or not it will take roots and is suitable for long term projects/time investment.

So when the NextNewThing(tm) comes around, feel free to jump on the bandwagon... just not for anything important in the first couple of years.

Answer 9

Mikeras answer is pretty nice. I'll add that future-proofing is a kind of security or risk management really. It often requires you to give up certain conveniences and cost/productivity benefits now to avoid problems later. I've been making nearly future-proof tech for quite a while now. There are certain patterns that can help. Here's a few.

1. Data should be stored in an open format that's easy to extract or transform later. Odd file formats are a big lockin technique & trap area in general. Also, prefer simpler approaches such as CSV, ASN.1, or JSON over complicated crap such as XML or, say, Word 97 format ;). The idea is that it's simple enough to throw a parser together yourself and the low-level format parser is reusable across your apps.

2. Applications ideally should have vendor- and tech-neutral interfaces built into them, plus a precise description of what they do. You should design stuff where you can change or throw away the implementation without breaking anything. Also, moving to a new platform is easy if your method of calling procedures or processing data works across platforms. So, the interfaces are the most important thing to get correct. The simpler, faster, and more open the interface implementation method the better.

3. The stack should be entirely open source and free to modify. GPL, LGPL, BSD, MIT, etc licenses are fine on this angle. The idea is that, if community starts dying off, then the stack might need to be moved to new [hardware/OS/protocol/etc]. And you need the code to do that.

4. The stack's design should be extremely modular with each piece being understandable by one person. This makes it easier for a new group to pick it up and maintain it. Having even the lowest levels of the runtime, libraries and compiler factored out nicely can have a huge payoff if it needs to be ported. Often, just that one part can be ported and all your old code will work.

5. Your app should be made in a modular way that factors out platform details to minimize rework in that area. It helps to structure functions into input/processing/output blocks where possible too. This can aid an analysis of what will be affected by a port (and correctness analysis in general a la' Cleanroom methodology). Lowest risk approach platform wise is to use lowest common denominator features that are supported about universally with one interface that lets you use them, further reducing porting. (I said you'd be loosing something...)

6. Dynamic typing, type inference or other flexible typing approaches help. A port to a new platform might change the definitions of the base types. Languages that do strong typing internally mean you worry less with this stuff.

7. Keep the concurrency model simple. Event-driven, message passing through clear interfaces is portable to... basically everything. There's also coroutines. You just want to avoid routes that are prone to both errors and portability problems.

8. Look at Mozilla and Apache's portable runtimes. They factor out many platform specific issues with certain interface and implementation choices. They can clue you in on what to worry about, along with providing good solutions to many problems.

Perfect example: Tcl. I know, plenty of people hate it and I rarely use it myself. Yet, Tcl is an extremely easy language to understand, implement (12 main rules), and code in. It's small, fast enough, integrates with Web servers, embeds in native apps, has been ported to tons of stuff, has certain safety features, and has been updated regularly since the 80's when it was made. You or I could implement a whole TCL runtime in no time for the core language. If we had to port the standard library, it would be easier than porting .NET or Java. And there's quite a bit of useful code written for it. And it's been used in web tech as far back as "mobile agent" craze that Java applets also aimed at. For instance, OpenACS web framework goes back to 1998 with server older than that.

Other examples: BASIC, COBOL and LISP (Scheme or CL). These languages all go back toward the 50's or 60's. They are simple enough to ease understanding, implementation and mechanical translation. Yet, you can build useful stuff with them. COBOL still powers most of world's transaction processing, has been updated a few times, & runs on .NET even. Old QBasic/QuickBASIC apps still run today with open/free tools on modern platforms, along with porting possibilities to better tools like GAMBAS or RealBASIC. LISP coders naturally make their systems modular and functional, easing porting. There's been a steady stream of implementations for it over decades, open and commercial.

So, interfaces, openness, simplicity, modularity, and platform-neutral architecture/design/coding. THESE will get you the future-proofing you require. Most of the time, anyway.