Monday, September 10, 2007

Choose the right tool

Everyday on Slashdot and elsewhere one comes across comments like PhP sucks, Ruby is slow, Rails doesn't scale, Perl is obfuscated, Java is slow etc. Most of these comments are posted by newbies(I being one of them) who don't have much idea about the "right tool" for a particular usage. So how do we choose the right tool ?
Well being an engineer I can tell you that this decision is should be based on optimal combinations of these factors(not in order of priority):
1. Load expected on the system
2. Amount of development time available
3. Quality of development resources available
4. Importance of the software being produced(critical/non critical)

5. Complexity

Expected load on the system: I think this one factor should play a major role in deciding the kind of tools to be used. If the expected no. of users on the system is in the order of 2000 requests/day, we can safely say that load is not much. However we must also keep in mind what is the distribution of this load. If there is a spike in the load at any given time of day/week/month/year which reaches, say , 200 req/sec for ten seconds and there is no load after that throughout the day, then the system must be capable of handling such loads. Therefore expected maximum load/sec multiplied by some safety factor (say 2) should be our design goal.
We must also consciously avoid premature optimization. Building a Google like system when we have a user base of 2000 is stupidity to say the least.

Amount of development time available(deadline): Some times it may be necessary to churn out some cool feature or application in short amount of time because it is sought after by the users. We cannot ignore that demand and sketch out an elaborate and mammoth design which would take months. It would be a better idea to code using some sort of "rapid prototyping tool" to gauge the user perception and then if it becomes popular then recode it into some other high performance language or "harden" the existing app by a code review.
Some amount of time should be kept aside for murphy 's sake

Quality of development resources available: This is one thing which should directly affect the tool being used. If we have a "super geek" team we can probably use any tool on earth. But sadly this is not the case most of the time and hence it is better to choose something which has a short learning curve and clear demarcations are available in the design to distribute it efficiently over a large non-high-quality team.

Importance of the software being produced: Well if we need an application which is not very critical or say some downtime would not hurt anything on the production side, then using a tool which makes life easy is a good idea. Also spending development time of a better quality resource is not that good an idea.

Complexity: Choice of tool should also depend on the complexity of the software that needs to be built. We cannot expect to build a complex application which say needs neural networks, backward chaining and symbolic calculations in php! Lisp would be a btter idea.

In my view before even we start designing a system we should create a list of the goals along with reasonable expected figures of key statistics. this would not only help us design the system better but also allow to take important desicions like no. of developers needs, technology to be used, amount of time expected for completion etc.

No comments: