Can we please just speak English?

Whenever a new technology appears, there is a short period of time where every body with an idea about branding want’s to “coin a phrase” or be the “first” to use a term.  As much fun as I am sure all that may be, the problem is that when the technology leaves it’s infancy and begins to stand on it’s own, we are left with a great many terms that we do not fully understand in our race to agree on the terms that we do.  One of the things I would like to do is provide you with a working understanding of certain development lingo, so that you do not find yourself in agreement with a salesperson who is selling you something very different than what you think you are buying. Such is often the case with Rapid Application Development.

According to Wikipedia, Rapid application development (RAD) is a software development methodology that uses minimal planning in favor of rapid prototyping. The “planning” of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.  James Martin’s Book, “Rapid Application Development”, makes reference to the need to make it up as you go along.  As far back as 1995 the term was being used by Ellen Gottesdeiner in “Application Development Trends” August Issue.  This is not a new concept.  Despite this fact, the cloud has brought it fully back into focus like never before.

What is important is to understand that Rapids Application Development is a process, not a tool.  A Tool that can assist in the process of Rapid Application Development is called a RAD Tool.  If you combine a RAD Tool with other RAD Tools, you end up with a RAD Suite.  They come in different flavors depending on where you are developing the application for.  As a Google Apps re-seller, I am predisposed to Google Apps, and the Google App Engine.  This is by no means the only way to go, it just happens to be the one I am most familiar with.

Now, to use the Google App Engine, you will need to write a program.  This can be done in Java, Python, or if you have a Linux Environment, you can even download the Go language SDK and write it in Native Go code.  Let’s assume you want the robust capabilities of Java.  We can also just say you have a Windows box and have no choice…either way works for this example.

You have two choices…you can start from scratch and build the entire thing from the ground up…or you can go get RAD.  Let’s imagine we have two companies.  We will call one “Alpha Soda Distributors”.  We will refer to the other as “Beta Drink Company”.  Both of these companies are competing bottlers, who have moved to Goggle Apps and have decided to develop an online application that will run on Google App Engine and be available to all devices and all users.  They have selected this platform because they are expecting expansive growth, and do not wish to be forced to scale their organizations software a third and fourth time.  Alpha Soda decides to use Giffy.  Beta Drinks decides to use the Java SDK with Eclipse.  Both start out just fine.  They plan, they chat, they bring in consultants to get the right information, and they are off and running.

Funny thing.  Three months have now gone by, and something odd is taking place.  Alpha Soda is using their application, and Beta drinks is still trying to work through the class structure!  Both are using the professional services of experts in their design, so why is one taking so much longer?  Because of the tools selected.

A Development Suite starts from a sheet of White Paper and allows you to do almost anything, but you have to decide how anything will be done.  A RAD Suite has a set of predetermined tools you can simply use-as-is to make the act of developing your application that much faster.  One specific example is that you rid yourself of writing boiler plate code for CRUD (CREATE, RETRIEVE, UPDATE, DELETE records in a normal Relational Database Management System application) operations which consume most of the time.  If you are going to write a stable application for Google App Engine, you need to keep in mind that Google App Engine DOES NOT support RDBMS operations, only access to the APIs, and you will have to fend for yourself and your data. This is where the time is lost.   In Giffy you create a Entity Kind deploy, configure the rules and start using “deploy to Appengine”.  This speeds things along, without sacrificing stability.

It is not impossible to do any of these things in Eclipse with the Java 6 SDK.  But while Beta Drinks runs into scheduling and cost overruns on their Google App Engine Development, and management starts doubting the validity of Google Apps and the competency of their IT Manager, Alpha Soda is reading their second quarter reports in Google of the information collected from the first quarter, complete with integration to Google Maps to show where their customers are, and Google Contacts to show who there customers are.

In short, knowing the difference between these two can not only save you a great deal of time, but a lot of money of those pesky scope-changing modifications that always seem to come from management at the least convenient times. If you happen to be a programmer writing an application for fun out on the appspot, then more power to you.  Grab the SDK and have at it!  If however, you are an enterprise with serious concerns about scalability, stability and development cycle costs…You might want to consider a tool like Giffy.