Selecting a website development platform

We are often asked why Webdragon uses an open-source LAMP (Linux/Apache/MySQL/PHP) platform for its technology. Much to the amazement of the person who poses the question, the answer is always quite simple. It has nothing to do with advocacy of open-source software or begetting the downfall of Microsoft. Instead, we use LAMP because it is the platform that Webdragon's founding developers know best.

It seems that a great many software development companies/organisations/individuals place a great deal of emphasis on the selection of the correct platform, without first asking themselves, What platform are we actually familiar with? While an enormous amount rides on the correct selection of platform, whether you choose ASP.Net, Java/J2EE, LAMP etc., what the developers are familiar with should be the single most important thing in making that selection.

Obviously each platform has its advantages and disadvantages. It has been claimed innumerable times that Ruby on Rails is a language-platform combination that facilitates extremely rapid development cycles. But are developers that willing to throw the baby out with the bathwater in failing to acknowledge that, while taking on a new language that may prove to be fast in the long term, in the short term they are throwing away the years of experience they have acquired in their language(s) of choice? It seems as illusory as any false economy (opens in new window) could be.

One of the areas where choice of platform can play a crucial role is in interoperability. If your application needs a live connection to an Exchange server, then ASP.Net is probably a good bet. But with that said, it is also the case that for less proprietary needs, this is exactly the job for which the early 2000s fad of web services and XML actually proves useful. If you need to interact with an obscure data dump produced by an equally obscure Java module, then write clever code that manipulates the data for you. If you actually have control over the data, then use an XML schema that is universally understood and maintained. Rather than instantly running off and purchasing "Java for idiots", perhaps consider the employment of the resources found between your ears (and cultivated over many years) and actually writing good code that does the job efficiently, in your preferred platform.

We remember only a few months ago hearing of a large corporation which decided it was time to switch from Macromedia Coldfusion to J2EE. Why would they choose to port hundreds of thousands of lines of existing code to a completely incompatible platform? Because they had heard how easy it is build portable code using J2EE, and, gosh, would they look professional after that! There was one problem, however: none of the developers knew the first thing about writing Java code, let alone porting hundreds of living, fully tested applications to a foreign platform. Even worse was that the managers who were chiefly responsible for the switch did not think that any particular prudence was required in the change over. It all seemed too obvious with foresight: With J2EE so easy and so portable, who would even need training, let alone a transition period? If only hindsight were so kind.

At another reasonably sized firm, many hundreds of thousands of dollars had been expended in developing a technology platform in a relatively obscure language. At face value, this might seem an unlikely candidate for success, but with reference to the continuation of the story, it is positively brimming with potential at this point. Rather than continue development in this language, or freeze the project and port it to another language (itself a daunting task (opens in new window)), the firm in question decided to begin porting the project to ASP.Net, and to develop and distribute both versions simultaneously. While most developers find it hard enough to cope with bugs inherent in simple mistakes in code and application logic in one implementation of a piece of software, it is a nightmare to deal with the same problem in two different languages, where a bug uncovered in one implementation may be the result of an error in that implementation's code, or in the application logic common to both implementations.

Coming back to the original question so often posed of Webdragon, the chief reason WebdragonCMS is developed in PHP on a LAMP platform is that it is what we know best. And that is the best way to ensure that we are delivering the highest quality code possible to the clients who use our software.