Use of Software Platforms (or Frameworks)
Software industry has been moving towards the adoption of software platforms in their products over the number of years. I don't mean platforms from SDK like .NET, C++ STL, or JDK. These are "essentials" to the language that they are supporting. Without them, these languages will be lying in software graveyards now. What I'm referring are platforms that bring in benefits other than language-based support for common coding tasks. These platforms generally provide an abstraction layer on top of the underlying programming interface to provide a more usable programming interface for the developers to work on. Examples:
- Qt from Trolltech for cross-platform development on Windows, Linux, etc
- Django, TurboGears, Pylons, Flex (and many more) for rapid web 2.0 application development
- Microsoft Foundation Classes (MFC), Cocoa (OS X), KDE, Gnome for GUI development
In general, coding on these platforms usually lead to shorter development cycles (when you have learnt how to use them effectively). The more "utilities" these platforms provide, the less code you have to write and you can concentrate more on your application logic. However, there are certain trade-offs that come with the use of these platforms.
From my experience, any time saved during development will cost you more time during runtime. O-R mapping for database objects, cross-platform coding, etc saves you time from having to deal with low-level issues directly. However, the platform will consume extra milliseconds from doing all these work for you, so eventually these milliseconds will add up and snowball into a significant performance penalty.
Now, the trick to this is to see at which load that this snowballed penalty becomes so severe that it starts affecting the usability of your application. If you are lucky, your users might just accept it to be part of the network connectivity issues and just wait patiently. Otherwise, you can always argue that it's a happy problem that the performance issue is due to the wide acceptance of the public and request for more funding to buy more servers or more hardware.
When you adopt a software platform for use, you also assume the responsibilities to test the platform as well. In cases of bugs, you may also need to find workarounds or to work with the platform developers to fix these bugs. You should also consider situations when the platform developers may not be responsive or simply ignore your pleas for the bugs to be fixed and the platform source code may not be available for you to perform the debugging.
My advice: do your users a favor and choose a platform that is easy to install. You will end up giving yourself less headaches, trying to troubleshoot with your users why your application installs but gives runtime errors due to failed dependencies. (This is a common issue in Python unless you are using setuptools /ez_install to auto-install the dependencies).
For opensource platforms, take extra care to mirror your dependencies on your server. Good opensource projects release frequently, but sometimes the new releases may obsolete and change their function signatures, and end up breaking your application after the upgrades. Another issue to be take note is that the opensource projects can die out due to unforeseen circumstances, and the softwares just disappear on the Internet.
In times of Bad Luck...
What if you have made a bad choice and select the wrong platform only to discover that you need a more advanced feature? Sometimes, requirements can change drastically and end up affecting your fundamental assumptions which you have assumed when you decided that the selected platform is the best in terms of development costs and time needed.
This has happened to me once when I had used Django for one project only to discover later that I needed to use vertical partitioning to re-model my data models because not all data reside in a single database. Pylons or TurboGears with SQL Alchemy can resolve this issue, but not Django as its O-R engine is built on the assumption that you need only one database for all your models.
To conclude, software platforms are useful and handy to work with, but there are cons which you need to evaluate carefully before deciding on their use. Otherwise, you may find yourself in sticky situations when it's really difficult to resolve without a full rewrite.