Do Not Go Gently Over to The Server-Side... | 2

[previous] [next]

Do Not Go Gently Over to The Server-Side...

Although some of the truths regarding the raisons d'etre of Web development components are self-evident, the reasons for choosing the right ones for your business aren't necessarily that clear. At their most fundamental level, any and all server-side Web development languages are simply tools to make our lives as Web developers easier (and sometimes more fun). Thankfully, most Web development languages do in fact deliver on their marketing promises; however, as it is with any component of information technology, some deliver much better than others. But, the primary step in any business's analysis of Web development tool selection is the definition of the business problem. Indeed, if there were no business problem, there would be no need to develop anything. Does the business really want to develop, using some form of server-side scripting language, application server and/or a Web-based system that glues their database(s) together with a Web front-end? Is that really the nucleus of their business problem? In a business context, what is the problem you're trying to solve? It's been said that a developer should spend considerable more time in the planning and analysis phase of the Web development lifecycle than in the actual development phase. Incorporating this heuristic into your Web development practices while simultaneously ensuring that you have a solid grasp on the business problem at hand will help you considerably with choosing the proper technologies and make it easier to achieve your goals.

Speaking of planning and analysis, it's not uncommon for certain companies to forego the whole analysis phase of the Web development lifecycle. This is unfortunate, as it will most likely cost the company severely throughout the Web development life cycle. Embracing a product simply because an attractive and reputable name is attached to it can be a mistake (though, in some cases, it can prove blindly beneficial, too). Another common company practice that should be avoided is, bandwagon tactics; for example, just because Company X is using PERL does not necessitate that Company Y should start using PERL. Realistically, one company's PERL is another's PHP4. To continue this example, there's very little difference between PHP4 and PERL (aside from the former being a derivative of the latter). Besides, both are quite impressive in their performance numbers. (Of course, these two languages reside exclusively within the open-source community, as both aforementioned technologies are non-proprietary.)

Where should we begin when we compare ASP running on IIS to PHP4 or PERL running on Apache, you ask? The answer in a word: outsource. Avoid the manufacturers' recommendations and marketing fluff and seek out the most objective third party that you can find. Examples of these companies are CNET or ZDNet. It's safe to presume that neither of the above companies are is on the payroll of the company's. At the risk of sounding redundant, these evaluators are in the business of evaluating, the foundation of which is (or at least ought to be) objectivity. A list of questions these objective evaluators may ask includes (but certainly would not be limited to) the following: What is the learning curve of this technology? Is the code open-source? Has there been upgrading considerations or issues in the past? How well will this technology (according to the technology manufacturer) integrate with what my company is currently using)? It should be duly noted that these are all very good questions to ask of any new information technology - not just a server-side Web development technology. If nothing else, these queries will save you time, effort and money in an anxious Web development marketplace.

When it comes to weighing the pros and cons of each Web development solution, the bottom line is that you need to seek out the most objective parties possible who perform these benchmarks. You want to know who's the best, eh? Don't talk with Linus Torvalds wannabes. They'll tell you that "Ugh, there's no comparison: use PERL or PHP4 running off of Apache in conjunction with Linux." (Anyone for LAMP?) Similarly, don't talk with any MCSDs (Microsoft Certified Solution Developers) either. They'll tell you that "Uh, there's no comparison: use ASP running off of IIS in conjunction with Windows 2000." In more than one way, they're warring factions. While there's something to be said for picking a side and sticking with that side, there's also something to be said for sticking with neither side until you've established an objective basis for your own opinion. The options are there; you just need to know where to look. What's right and what's wrong? See guideline number one above. Not surprisingly, each solution has its own pros and cons. Both the above technology choices have been proven in the IT marketplace. The difference between the technologies lies in where, how and why they are best applied.

[previous] [next]