Rapid Application Development – In Plain English

Enough Already with the Excess Words...

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.

Chance Favors The Prepared Mind…

Best Practices are defined as a method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark.  What this means is that they have actually been proven.  Proven?  How do you prove that one method or technique is objectively better than another?

Best practices come with real-world examples that can be measured with comprehensible metrics.  Take a newsletter, for example.  You can spend all day having meetings on how to get more names on the mailing list.  If this make-believe newsletter is designed to promote the sales of your new product, best practices would be measured by how many items this newsletter actually converts to sales.  Before doing this, you would need a benchmark.  Who else is using a newsletter to draw in sales?  Why are they successful?  What is the magic number which identifies success and differentiates it from failure?  Metrics are where the rubber meets the road.

Before you make any major decisions about changes to make to your technology, switching vendors, or replacing one tool for another, pay attention to the metrics.  What are you measuring?  How are you measuring it? What do the measurements mean?  Seem abstract?

Let me provide you with a real-world example:

Client A (an actual company, a client of mine), has been sending out an email newsletter every three days with a great many items listed.  Anyone who knows metrics and has studied open rates, knows that the hero product and three minor products are the MOST that the average user will read.  We know this, but we cannot quantify it.  Despite all attempts over the period of two years, and several re-designs, it was impossible to get it through managements head that less is more when it comes to newsletters.  Worse, being able to show the mailing list dropping from 12,000 names to 8,500 names over a nine month period of time did not convince anyone of the need for change.

Client B (another company), was doing the same thing, but they decided to use Google Analytics along with Google Adwords and actually send out three copies of the same newsletter, with slight changes, to different segments of their customer base.  Because the proper codes were entered into the newsletters and Adwords, there was a direct correlation between the sale and the advert it originated from.  The difference was so extreme, that their newsletter policy changed the day the report was printed.

I am now working towards assisting Client A in adding the metric to their newsletter.  So far the resistance has been about the lack of “time”.  I have yet to get them to understand than the reason they are so busy is because they are doing it the hard way.  They are so busy cutting down trees that they have no time to sharpen the saw.  It is their choice, but their mailings are becoming less and less effective with each passing week.

So, if you are trying to operate as an agent of change within your organization…

…Push for the metrics.  They are difficult, time consuming, and irritating.  Nothing, however, gives you better tools for improvement tomorrow, than the ability to quantify how well  or poorly you are doing today.  Your competitors are not beating you because they are lucky or smarter than you.  They are beating you because they can do the math.  They are winning because they can see mathematically where they need to improve and what they need to change.  You, on the other hand, are relying on anecdotes.  When change comes, and it always does, you will not have the metrics to measure the change, leaving you unprepared on how to respond to the paradigm shift.  This delay will allow your competition to pass you and leave you in the dust.

Chance Favors the Prepared Mind.