|
|
Re: Use the Best Tool for the Job
|
Posted: Dec 1, 2003 9:29 PM
|
|
I find many programmers don't understand the relationship between their code and the systems their code rides. They overdo it, driving up costs and the time of delivery for the sake of bullet proofing.
The reality is the correct tool for the job not only encompasses the choice of language, but also the hardware and network environment the resultant application will reside. They must complement each other for the task at hand.
For example, lets say we have an internal application that at most 50 people will use in your organization. Response times are not critical (we are not building the space shuttle here). Now given that the worse case senario is 50 connections, and more likely an average of about 5 or 6 connections at any given point in time, what would be the correct solution? Many times this ends up being a java or C++ application running on a fully redundant mirrored environment (perhaps MC Service Guard environment on a high end HP). In reality, the application could be emplemented on a Sun Blade/Ultra single processor box with an automated backup routine using readily available Zope and Python. It would be implemented quicker, the users would be able to give more immediate feedback, changes would be trivial, and the developer would really serve the users what they need when they need it.
The problem is we think in terms of gold plating and bullet proofing our applications in various ways - at both ends of the spectrum. Not only do we use the most 'stable' and/or 'efficient' language implementation, we then further elimenate all possible exposure by over engineering the hardware solution. I think some of this stems from the overspecialization of programmers. I often question the motivations of anyone who refuses to learn new languages, and other aspects of system development outside of their area of expertise.
Every project is not the space shuttle - in fact, <i>most</i> are not. Outside of mission critical code (such as nuclear reactor code, or code that controls the space shuttle engines), imperfect working code in the hands of users now beats perfect code 14 months from now.
(To toot my own horn, I have built programs using the following languages: basic, fortran, C, C++, Java, Perl, Python, sed, awk, sh, csh, tcl/tk/expect, x86 assembler, sparc assembler, and lisp)
|
|
Previous Topic
