The Programmer's Toolbox, part 1

In the beginning ...

The web was a very simple place. A "web page" was most likely to be a "static" page, meaning what we saw was the result of just the HTML code in a single file. Modern "web pages" are dynamically generated from data stored in a database server. They are displayed using templating engines and other more advanced techniques, all the while being accentuated with liberal doses of JavaScript and CSS.

Back in the day, on the rare occasion when a web page needed to talk to a web server, a "CGI" program (Common Gateway Interface) would do the talking. In all likelihood, this was written in the ubiquitous language of the day, "Perl". If you knew some simple HTML and some Perl, you could really do it all, man.

And just as the web itself was simple, so were the tools we used to build web pages and web sites. A simple HTML file could be written with a basic text editor (like Notepad), or maybe if we got fancy, we would use Composer from Netscape Communicator Suite of Internet tools. You couldn't use web-specific Microsoft products then, because they didn't exist.

But now you can't think about building anything on the web without a box full of serious programming tools. The good news is that there are plenty of tools to choose from. There's a variety of languages to choose from, frameworks to support those languages, different IDE's (Integrated Development Environment), editors that are available specifically for your language of choice, and a choice of database server implementations.

In many cases, a given project can be done with any set of tools. The finished product we deliver will be a mix of standardized open technologies, such as HTML, CSS, and JavaScript. These are the true languages of the web and the only languages a web browser is capable of utilizing.

For the most part, no matter what choices we make on the development path, we will all wind up at the same place technologically. A typical user will never know whether we used Java, Ruby, or .NET to generate all that HTML their browser is displaying, so how we choose to deliver the finished product is often up to us. However, there are occasional exceptions when the project requirements limit what tools we can use.

When starting a new project, we want to use the best tool for the job. Although there are a variety of choices, not all choices are equal. So how do we decide which tool is best?

Factors to consider include:

• Adaptability: How much of the heavy lifting of the project can be done by the language and framework, and how much functionality do we have to create from whole cloth?
• Extensibility: How easy is it to extend and modify the built-in features to help us with the task at hand?
• Scalability: Does our toolset help or hinder us if we have to start sharing the load amongst multiple systems? Or datacenters?
• Maintainability: As the project we are creating evolves over its lifetime, and perhaps takes unexpected turns, how well will the given toolset be able to grow and expand with us? Or will it get in the way of unseen future requirements?
• Documentation: Do we have good developer level documentation?
• Support: Where and how do we get support, and how good is it? For paid software, most support comes from the provider. From open source and free projects, this is either the developers or other users (which is not necessarily a bad thing).
• Familiarity: If we are hiring outside developers, we obviously want to choose those that are intimate with the tools we have chosen. If we are using in-house developers, how well do they know the language and framework? The devil you know is often better than the devil you don't, which translates directly into increased productivity.

Some tools may be better suited to certain projects than others, in that they bring something to the table that significantly reduces development time. For instance, using Eclipse as an IDE for Android app development would be a good choice. Google has made specific extensions available for Eclipse that helps push the development process.

The bottom line is to find which set of tools will meet all of the project requirements and get the job done in the least amount of time.

To be continued ...