Pick the Right Tool for the Job
by Brian Dunning
digg this article | del.icio.us this article
I'm often hassled because the shopping cart that I built for many of the web sites on which I sell software products I sell is written in PHP, and among my products are Lasso courses and Lasso code snippets. One guy even suggested publicly that it reflects poorly on Lasso that I don't even "trust" it for my own stuff.
Hassling me for this reason suggests a deep misunderstanding of why technology decisions should be made. I don't agree that the overriding concern should be pleasing the potential Lasso class attendee by showing him that his registration was completed using Lasso. Sure, that would be nice, and if all else was equal, I'd probably have done it. But a more valuable experience for a student would be to learn what considerations should be taken into account when making a technology decision, and then to apply those considerations and make the best selection.
In this particular case, the server in question was a virtual host on a shared server at an ISP that didn't offer Lasso, like most ISPs. End of story. Yet my tormentors interpreted that I "didn't trust Lasso."
From which airplane salesman would you rather be guided to the best aircraft for you: a guy who sticks to a single type of plane, refuses to test any others, and knows everything about his own plane but nothing about any other; or a guy who has flown them all, used them all, and has a deep knowledge of many types?
So let's talk in specifics. When I'm deciding which technology to use on a web application, here are some of the environment variables I'll look at:
- Existing infrastructure. Are there any existing systems or databases that this new system will need to play nicely with?
- Deployment environment. Where is this going to be hosted? What kind of remote access will be needed and available? What operating system is going to be used? Are these decisions dependent upon my decision, or is my decision dependent upon them?
- Development, hardware, and software budgets. Is money available to make the hardware and software purchases that my decision will mandate, and what kind of development budget is there? Don't be discouraged away from a logical course because a project with a cost of tens of thousands of dollars is going to require a purchase a several hundred dollars: keep your eye on the whole forest. Be dollar wise, not penny wise and dollar foolish.
- Maintenance situation going forward. Does the owner of this new system want a large talent pool to draw from for assistance in the future, or is he going to be dependent upon a very small pool of talent who might get hit by a bus? Is it important to use familiar, widely used technology?
- Anticipated load. Is the expected load truly going to be enough to overwhelm FileMaker Server? Many people seem to fear this but I've never seen a site that could come close.
FileMaker Server is great and wonderful, but it also has its drawbacks, as does any technology. It's important to understand these drawbacks, and those of the competing choices. In my experience, it's best to use FileMaker Server for your data source when the application is going to be hosted locally, and local FileMaker users want live access to the same data that's driving the web site. If that's established, and Mac and/or Windows are available for hosting, the next question is to decide on the web application technology. There are many from which to choose (Lasso and PHP being the most prevalent), they all work, and the desired end result can be reached with any of them.
If FileMaker Server is not going to be used, then chances are strong that I'll recommend PHP/MySQL. I use PHP/MySQL for probably 80% of the web work that I do. It's highly optimized for any server platform, fast as hell, and has a huge base of programmers out in the world who can pick up the pieces if I get hit by a bus.
The primary difference between PHP/FileMaker and Lasso/FileMaker is the query structure. With Lasso, there are zero code changes needed to switch between a FileMaker data source and a MySQL data source if you decide to migrate later. With PHP/FileMaker the needed changes are significant.
The only real limitations with either is that you need a Mac or Windows server to run Lasso or FileMaker Server Advanced, and neither is something that most ISPs are not likely to run unless you colo your own server. Some feel that this is offset by Lasso's excellent administration consoles, a feature missing from both PHP and FileMaker Server Advanced.
Usually the decision whether to use MySQL or FileMaker is straightforward, but not always. Sometimes half of the puzzle pieces support one model, and half support the other. Compromise configurations are possible, including some interesting things you can do with remote synchronization using SyncDeK. Other times, completely different technologies arise as the best choice. I've even used JSP/FileMaker in one case, because it fit in with the existing infrastructure. I used to do a lot with PHP/PostgreSQL, Witango/FileMaker, Tango/Oracle, PHP/Oracle, and even JSP using a dynamic text file for a data source!
All of these technologies are rich, full featured languages, well proven, with all modern programming constructs. There is no issue of "trusting" one and "mistrusting" another, which makes one of my detractor's comments just plain silly. Anything you need your site to do can be delivered just as well using practically any technology. There is never any need to ask "Can this be done with Lasso?" or "Can FileMaker support a shopping cart?" Of course they can - anything can - there are far more substantial considerations that the knowledgeable developer with foresight needs to be aware of.
Keep platform religion, personal bias, and inexperience out of the equation. Often, a developer is thrust into the role of product manager, as many consulting clients lack a staff member with the proper expertise. When this happens, be up to the task. Bring an unbiased eye to a project, look at the big picture, and make the right decision for the right reasons.
