Slashdot Mirror
Ask Slashdot: How Do You Choose Frameworks That Will Survive?
First time accepted submitter waslap writes "I have a leading role at a small software development company. I am
responsible for giving guidance and making decisions on tool usage
within
the shop.
I find the task of choosing frameworks to use within our
team, and specifically UI frameworks, exceedingly difficult. A couple of
years back my investigation of RIA frameworks lead me to eventually
push for Adobe Flex [adobe.com] as the UI framework of choice for our future web
development. This was long before anyone would have guessed that Adobe would abandon the Linux version of Flash. I chose Flex
mainly for its maturity, wealth of documentation, commercial backing, and
the superior abilities of Flash, at a time when HTML 5 was still in the early stages of planning. Conversely, about 15 years ago I made a switch to Qt for desktop applications and it is still around and thriving. I am trying to understand why
it was the right choice and the others not. Perhaps Qt's design was done so well that it could not
be improved. I'm not sure whether that assessment is
accurate.
I
cannot find a sound decision-tree based on my experiences to assist
me in making choices that have staying power. I hope the
esteemed Slashdot readers can provide helpful input
on the matter. We need a set of fail-safe axioms"
Read on for more context.
The backing of Adobe, an industry giant, gave me what I later discovered
was a false sense
of security. I thought that the Flex framework would not get lost in a
back alley like so many
open source projects. We invested heavily in Flex and were
disillusioned a couple of years later when Linux support for Flash was
ended. (Linux support is vital for us for reasons outside this
discussion.)
I had evaluated Adobe Flex alongside OpenLaszlo, which at the time had the ability to use a DHTML back-end instead of Flash with the flick of a switch. In retrospect, this alone apparently made it a better choice in the long run regardless of its flaky state when I first looked at it.
A similar scenario arose with CodeIgniter, which we chose for getting away from classical spaghetti PHP. CodeIgniter was recently dropped after we've invested a Tesla Model X worth of money into using it. (EllisLab Seeking New Owner for CodeIgniter.)
I am standing at a cross-roads once again as people are pushing Laravel [laravel.com] for PHP, and giving other suggestions. I am scratching my (sore) head and wondering how to prevent eventual failures in the future. It seems there is no way to predict whether a tool will survive.
Even in retrospect, when I consider my decision-making processes, everything was reasonable at the time I made the choices, yet some turned out to be wrong.
I had evaluated Adobe Flex alongside OpenLaszlo, which at the time had the ability to use a DHTML back-end instead of Flash with the flick of a switch. In retrospect, this alone apparently made it a better choice in the long run regardless of its flaky state when I first looked at it.
A similar scenario arose with CodeIgniter, which we chose for getting away from classical spaghetti PHP. CodeIgniter was recently dropped after we've invested a Tesla Model X worth of money into using it. (EllisLab Seeking New Owner for CodeIgniter.)
I am standing at a cross-roads once again as people are pushing Laravel [laravel.com] for PHP, and giving other suggestions. I am scratching my (sore) head and wondering how to prevent eventual failures in the future. It seems there is no way to predict whether a tool will survive.
Even in retrospect, when I consider my decision-making processes, everything was reasonable at the time I made the choices, yet some turned out to be wrong.
That thing will be around FOREVER!
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
Depending on what you're doing, you should consider writing your own framework. I love using the one I wrote from scratch 10+ years ago: it's proven, high quality code, there are no secret corners I don't understand, and I know how to fix or modify it to do new things. It's also small and fast because it only needs to solve the problems *I* encounter.
To anyone who starts preaching the religion of code reuse, I think you're just scared of the unknown ... or not a very good programmer. The sorts of things most people need a "framework" for are so simple that any experienced programmer should be able to do it.
Whatever shows up (significantly) on the hiring boards.
Choose the framework that supports, or can be extended to support, planned features of the product.
Thanks captain obvious.
Most folks who want to use a framework have no interest in forking or taking over the project. They want something that works that they can use to save them time. Writing your own from scratch, or maintaining can be a lot of work. That's why some folks are willing to pay for a framework. They defray the cost by only paying for a small portion of the development cost that's shared with others.
If they can pay someone in-house to fork/maintain, they can probably afford someone to write a customized framework that fits their use-case better than a generic one from either an open or closed source provide.
Ultimately, it's nearly impossible to predict market forces and corporate decisions. You made a good choice in both cases based on the information available. There were good communities and significant momentum behind both frameworks at the time. You could post-mortem the decisions endlessly and surely find "signs" that you could use when evaluating for next time, but guaranteed there will be different forces in play when (not if) it happens again. Don't beat yourself up about it, and don't let anyone else, either.
Capttain Obvious (GP) here...
You don't have to do it yourself, just piggyback on somebody else who takes over the project.
Look at what happened when Oracle lost interest in OpenOffice, or when they started to do weird things with MySQL.
Firstly don't design your software around the view. Consider separation of your data structure from your view (MVC architecture), so the view is easier to replace if necessary.
With that said, I've done extensive development in Flex, openLaszlo, and Qt (PySide). I really enjoy all three, but lean towards Qt development (PySide/PyQt). I tend to get quality (designed, tested, nerd approved) product out much faster. Furthermore I'm not a big fan of the lore that comes with the flash plugin, or browsers in general. Of course I do deal with some cross platform inconsistencies with Qt.
Been there, done that, wondered "What were we thinking?"
In selecting an instrumentation framework for a test system, we went through a careful process of defining what was important, listing the pros and cons of each competing option, ran some tests to see if both would run the instruments we needed, ... Aaaand chose the worse option of the two, as events ultimately showed. The choice was evidence-based, reasonable on the basis of what we knew at the time, and suboptimal. The system worked, but we had to do some ugly stuff to make it work.
Sometimes you just can't outwit Murphy.
"My strength is as the strength of ten men, for I am wired to the eyeballs on espresso."
In what respect is C# and .NET "not going to be around for long"? AFAIK, Microsoft's roadmap doesn't include getting rid of them any time soon. They're too important for LOB applications.
Pick a single product at a single version that wont work with anything else.
Second, make sure its old and obsolete already.
Third tie the whole company processes for everything under the sun even outside the project. Make sure they all use it and save data to its own format. Encrypt it to a password only you know.
Last note EOL of platform and quit.
One year before EOL offer your services for $250 as a consultant.
http://saveie6.com/
I've been faced with this kind of decision a number of times. I always remember: if I'm not filthy stinking rich right now, then I'm probably bad at predicting the future. Any attempt to do so should be taken with a huge dose of scepticism.
That said, I think that the practical answer is simple: invest a bit of time doing a bake-off of the likely candidates. Try to choose some real high-priority business features, and then get very small teams of 2 or 3 people each to use each of the frameworks to build production-quality functionality for those business features. Don't take more than a week to do this. To use your example, Flex vs. HTML5, you would get two small teams to try to build the _same_ functionality using the two different frameworks.
Evaluate your results based on how much the teams actually got done. (Remember: production quality, not prototype quality.)
Since you can't predict the future, I also strongly recommend good Agile Engineering Practices to help to build a system that is not just change-tolerant, but is actually easy to change.
Helping with organizational effectiveness is our job.
Perhaps he should have chosen the platform correctly. His problem was choosing the wrong platform, not the wrong framework. It doesn't matter which Flash framework he used if Flash as a platform didn't survive. Might as well have chosen ActiveX if he wanted to put himself in a corner.
Truth be told: Tools won't survive. They're notoriously fickle. That said, this is one place where good development practice can really help. Here are some of my guidelines:
Get off the bleeding edge. Let the youngsters and startups do the bleeding. Learn from them, and use cutting-edge tools after they've matured a bit and have widespread market adoption. Yes, I was late to the jQuery party. No, I don't feel bad about that, as I could have just as easily chosen a failed alternative and been left with something that's damn near impossible to maintain.
Quality separation of concerns is VITAL for survival. Keep your data store separate from your business logic, and for Knuth's sake, keep your UI the HELL away from everything else, since the UI is the most volatile bit.
Don't resist your platform: Working on the web? Learn JavaScript. Learn jQuery. Do not use things like SharpKit to turn one platform into another.
Use things for which the were initially intended, and ignore many of the add-on features. Use databases to store data, not as process engines. Use JavaScript / jQuery for user interface goodness, not your entire application logic.
APIs / web services / interfaces are your friend... Not just to use, but for you to enforce separation and flexibility.
This sig has been enciphered with a one-time pad. It could say almost anything.
Must be the time of year, I read the title as Fireworks instead of Frameworks, and my first impression was "don't light it".
But that depends on other parties with the will and capabilities to support the framework having an interest. Being open source definitely is an advantage but by no means a guarantee a project will survive. Sturgeon's law applies to open source software just the same as to proprietary software.
The request of the submitter for a fail-safe set of axioms can never be answered. With fail-safe systems tending to fail by failing to fail safe. But with common sense a few indicators of long term viability are easy to give:
1) Who controls the software ?
If it is a single party chances are good it will be abandoned at some point in the not so distant future. Open Source can help with this point but as said earlier it is no guarantee. There are many open source projects which are for all practical purposes developed by a single company. These projects are just as likely to be abandoned as commercial software.
2) Who uses the software ?
The more people use the software the less likely it is it will be abandoned. For commercial proprietary software a big user base means income and companies are not in the habit of slaying the goose that lays the golden eggs. For open source software it means there is a bigger potential pool of contributors to continue development if a main developer exits the project.
3) How long has the software existed ?
New software is continuously written and released. Again according to Sturgeon's law 90% will be crap. It will take a little while before the writers realizes their software belongs to this majority and stop supporting it. The longer software has been actively developed the less likely it is to be crap and discontinued.
4) What was the motivation for creating the software ?
If the motivation is a specific goal other than meeting the needs of the users expect the software to be abandoned if it becomes clear that the goal is unrealistic. If the goal is met the software might be continued. Think about lock-in strategies and subverting standards in this regard.
The choice for Adobe Flex had issues in at least point 1, 2 and 3.
Step 1: Ensure your whole toolchain (libraries, tech, etc) is either open or too commercially essential/purchasable to obsolete (Win32 libs).
Proof: There are old PHP code that hasn't been touched in 10 years but can be improved easily.
More proof: When the incompatible Python 3 came out, years went by where the other environment was maintained, and now for most code you run the converter and you're set. No commercial interest would have taken that much care.
Step 2: What is BIG? _Size-big_ On most resumes for the field big.
Proof: Oracle's Java interpreter is so insecure that you can't use it in browsers anymore, yet it persists everywhere it can because the engineers know it.
Step 3: Don't put a lot of dependent code on-top of it
Frameworks don't last, but neither does the product you're creating. If you don't have much code atop the framework, moving to another will be easy. If it will take a lot of code to make your tech work on a framework, it's better to fail fast. Keep your code atop the framework modular so you know where your integration points are.
Step 4: Be the integrator.
If you rely on many small libraries (who doesn't), be sure you are-or-run the glue and not their compatibility. It's more code, but allows you to entirely replace a library that doesn't live up to your changing needs.
Step 5: Model Linux's ecosystem: standards win since they're multiply-implemented. /proc sources of the C API wrappers source from.
As the most research-able long-lived full system, you see lots of libraries, fickle front-ends, separate long-running processes (daemons) to manage long-running and security-intensive operations. Large programs are broken into smaller programs which are each audit-able, replaceable, reusable, easier to divide labor, etc. Programs with the longest life depends on standard wrappers like the C libraries (which many libraries implement identically-enough) and not on the fickle kernel
Science & open-source build trust from peer review. Learn systems you can trust.
What I've found works well (90% of the time) is:
1. Look to see if people are hiring for that technology. If you check dice.com or something similar you'll see if companies are invested in it.
2. Are 3rd parties building "plugins" or "extensions" for it?
3. Does it make sense to you? Does it adapt well to your needs? Is it well designed?
While many frameworks may be cool or superior technologically, the sad thing about software is that popularity DOES matter.
There wasn't room in the subject, but I should add "with stable APIs."
Things like Qt, GTK, OpenJDK, Apache, and PHP, to name a few. These are all so widely used that even if they were abandoned by their current maintainers, someone else would pick them up and at least patch them so that they continue to work. This someone wouldn't have to be you. And yes, I know everyone hates PHP, but the fact is, a lot of the old cruft is still there to ensure backwards compatibility, and much of it has been superseded by cleaner OO interfaces. Much like with Java, they're making a lot of effort to make sure that your old code will continue to work with at most minimal changes, and if you're looking for something that will work for you in the long term, this is really helpful.
Failing that, your best best bet are expensive proprietary frameworks that will contractually guarantee some term that the framework will be supported.
After that, big open source projects with less stable APIs (I'm looking at you, Drupal). Drupal is big at the moment, but their nasty habit of breaking everything every two or three years is likely to lead to a fractured community and eventual abandonment of the software unless they can get their APIs stabilized enough that modules will continue to work from release to release. It looks like maybe they're trying to do that, but the pattern thus far is that they haven't. Regardless, if you see a framework with a constantly changing API, you're probably taking more of a risk than you would be if you used a mature product, even if the userbase is large. On the other hand, a large userbase does provide a certain amount of protection against obsolescence. I'm not saying that Drupal is a particularly unsafe framework (I'm quite fond of it myself), just that their development process might lead to intractable problems down the line. Note that GTK and Qt make occasional major API changes, but these are infrequent, and there are so many users of the older versions that linux distros tend to keep the old code around just to make sure things will work.
After that, probably small open source projects. At least if those are abandoned you'll have access to the code. But before using an open source platform with a small userbase, make sure that you have the time and technical expertise to maintain it yourself if it's abandoned. Most likely, you don't. Also, large, complex open source projects with a small number of users tend (in my experience; I'm sure there are exceptions) to be buggy and poorly documented.
The worst offenders are free or cheap proprietary frameworks that don't come with any sort of guarantee, like Flex. In those cases, you're at the mercy of the whims of a commercial interest, and when the product you depend on becomes unprofitable, you're cut off with absolutely no recourse.
It may be difficult to tell, but I would ALWAYS choose a platform that had capable independent fans over one backed by an enormous corporation. Single entities abandon things seemingly on whims (OK, well actually, expectations of profit, sometimes by folks who can't predict there'll be wind accompanying a hurricane). But if there's a viable community of folks who aren't just fans, but are capable of providing some kind of momentum and support, then the platform will probably survive until something unequivocally better comes along (at which point you would probably want to switch anyhow).
But, for the most part, those are small projects which are unlikely to have won the submitter's approval in the first place. His other examples were giant projects like Qt and Flex. You can bet that if Adobe open sourced Flash, someone would maintain it for Linux.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
The best you can do is design so that moving to something else is possible instead of painful.
How is this possible when widely used frameworks are designed for one language and one language only? For example, the web runs on JavaScript, but if I remember correctly, Flex used ActionScript and Silverlight used C#. I can see rewriting the user interface when switching frameworks, but rewriting the application logic in a different language for each framework can get very tedious and introduce plenty of bugs.
If a company or any organisation which develops an open source framework ditches or otherwise nukes it, anybody else with an interest and the capacity to do so can take over or fork it.
Nobody will be able to use this fork if the majority of revenue comes from people who own closed-source devices whose manufacturers refuse to implement the framework. This has become true of the iPhone and iPad, for example, whose Safari web browser can't run Flex despite the existence of Gnash and can't run Java applets despite the existence of OpenJDK.
In order to bet well on a framework, you have to pair general population with investment psychology. For example, let's look at Code Igniter.
CodeIgniter is a PHP framework. There are A LOT of PHP frameworks. The reason there are a lot of PHP frameworks is because of the language and the community. Most other languages are specifically built for web development, so the frameworks in them add all of the tools you need to handle web development more efficiently. Because PHP has so many of those tools, everybody rolls their own framework. As PHP frameworks become more mature, you start to see speed issues because unlike Java/Python/Ruby/.NET ALL of those PHP files have to get loaded on every request, creating a lot of disk I/O. It's server-suicide to use a PHP framework without APC configured. This leads to a conundrum of framework maturity vs framework speed in the PHP space. The language needed 5.3 and 5.4 to make frameworks REALLY feasible.
But without even getting into all of those details, the sheer fact that there are dozens upon dozens of frameworks in the language is generally a HUGE red flag. If there are that many choices, nobody has got it right. If there isn't one, distinct, clear leader in the space then there isn't going to be an ecosystem AROUND the framework contributing to plugins, etc. Additionally the framework fragmentation will generally mean that you will have a very hard time finding people who use the language who already know that framework. I spent 5 years as a CakePHP developer and I've lived everything I just described.
The end result is that if you want to use a framework PHP itself is a bad choice because there isn't a great option. PHP is great for many things, it's just a valid point in the framework discussion. Because of the level of framework fragmentation your choice of framework is basically "how do I want to organize my code" as the only actual benefit...which really is almost the same thing as just rolling your own.
If you look at other languages:
Ruby has Rails .NET has MVC
Python has Django
Groovy has Grails
For the last 2 years, I've been using Ruby on Rails. For one thing, it's basically the standard bearer for web frameworks. Within the ruby ecosystem, pretty much EVERYTHING makes sure that it works smoothly with Rails. It was really the clear choice from the time that I was making choices the only thing that prevented me from using it was the very stubborn "but I already know PHP" line. I looked at Groovy so I could deploy on Java infrastructure, but jRuby solves that problem for Ruby as well. If I was in a .NET shop, the choice would be MVC and if I was using Python it would be Django. Until PHP gets a "main" framework, there will not be a good framework option for PHP. Laravel seems to be going the right direction though, so that's one to keep an eye on.
In the front-end space, anything Flash based has pretty much always been a bad idea unless there is no alternative. Front-end web development should generally always follow a philosophy of graceful degradation, meaning everything should work without javascript and javascript should be used to enhance the experience with only a few exceptions on the actual-in-browser-application front. jQuery made graceful degradation EASY while also emphasizing compatibility (you could use jquery and prototype at the same time, that wasn't the case with most JS tools) and as such, took over in popularity.
The short answer to all of that is simply this: the market leader leads for a reason. Look for the market leader that works across the broadest set of platforms and you'll generally find your answer.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
With Silverlight dead, XNA dead (which was a multimedia and gaming thing), one might be under the impression that XAML is dead too and that WPF will be deprecated and .NET will end up being just server stuff like Java. A gross misconception from someone outside the .NET ecosystem maybe but that's perception.. Also the fact it's mostly only used on Windows desktops and servers.
It's impossible for a UI framework to stay relevant for more than a few years, unless it's based around a slow-moving standard too big for corporate interests or bottom-lines to affect.
Your choice to use something other than HTML5 because HTML5 wasn't ready yet, was good. However, you probably should have used something HTML4 related at that time.
As someone who's been predicting Qt's demise ever since he learned Nokia had bought it, I can only shrug and wish I'd been there to tell you so.
Do not rely on corporate frameworks, ESPECIALLY open source ones. Corporations treat open source projects as hot potatoes the second money gets tight. They only keep them on board to reduce costs and gain a little PR magic with the less-cynical geeks. As soon as it starts costing resources to improve and especially if the non-paying user base gets uppity (which, as a monied stakeholder, you can't control), out the window it goes.
Since corporations get their fingers into everything they rely on, your rule of thumb should be the ratio of unattached volunteers (those working on the project in their spare time regardless of who they work for -- meaning their employer had no influence on their choice to volunteer with that project). If total project brain drain is just one cost-cutting decision away, that framework is dead code walking.
Every trollism an AC posts is prefixed, in my mind, with "A. Coward whined, in a weak and cowardly voice:"