Ask Slashdot: How Do You Choose Frameworks That Will Survive? 227
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.
Write your own! (Score:5, Insightful)
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.
Practical answer (Score:5, Insightful)
Re:Open source survives (Score:4, Insightful)
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.
Hindsight is 20/20 (Score:5, Insightful)
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.
Re:Open source survives (Score:2, Insightful)
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.
Qt (Score:5, Insightful)
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.
Bake-off (Score:4, Insightful)
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.
Flex is a Framework but Flash is a Platform (Score:5, Insightful)
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.
Some notes from a seasoned web developer... (Score:5, Insightful)
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.
Re:Write your own! (Score:5, Insightful)
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.
This is a challenging option in a corporate environment when you need to hire someone to support said framework after you have left the company unexpectedly.
Re:Practical answer (Score:5, Insightful)
This is an insightful answer, and I wish I had mod points now.
What's on job listings gives a good indication of what other companies have invested in, and what they're going to need support for in the next decade.
Re:IE6 (Score:5, Insightful)
My Criteria (Score:5, Insightful)
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.
Large, old, widely-adopted open source projects. (Score:5, Insightful)
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.
Re:IE6 (Score:4, Insightful)
+1 Funny and -1 Not Funny in one sentence.
Re:Design for multiple languages (Score:4, Insightful)
Accept that the price of using a framework is probably re-writing everything every few years. Don't lie to yourself about it. This is the fundamental problem with frameworks: even if they don't go away, mature projects often hit their limits.
I don't think that any framework is a good plan for a well-funded successful project - for the few projects that make it there. So I'd say: take the framework that gets V1.0 done quick and easy. Probably the framework will die, but that's OK because probably your project will die first. If the project is one of the very few that really takes off and is a big deal 2-3 years later, then you'll have the resources to do it right.
Re:Open source survives (Score:1, Insightful)
Open Source is the Free Market at work. If a technology proves useful, there will be people that are going to be supporting it for as long as it remains useful. If a tech doesn't get wide adoption and people don't see a use in it, it's not going to go far. I argue that if a framework is Open Source, it will last longer than any proprietary format. If no one takes over a project, it's quite likely because no one sees a use in the technology in the form that the project took.
Also, look at it from this way: Microsoft's .NET is still a very popular programming framework in the enterprise, despite its flaws. Microsoft has every bit of power to say that effective at close of business today all .NET development will cease, all licenses are hereby revoked, and no new licenses will be given. Congratulations, every Enterprise that's been relying on .NET for their day to day operation has just been royally fucked and need to adopt a new framework standard to rewrite every single one of their applications YESTERDAY!
Granted, that scenario is hypothetical and not very likely, but it is a very real example of the limitations of reliance on a closed source framework. QT, an open source framework, worked well for the Waslap. If he went with GTK+ it may not fare so well considering the state of Gnome and uncertainty of direction (how many forks are in the wild now?) but it would not have to be a cold turkey forced migration but rather it could be relatively easy to begin a roll over to another available open standard in a phased solution since (correct me if I'm wrong here) it couldn't be done as an immediate all at once license pull.