Christopher Littlefield has been providing custom software solutions to businesses and individuals since the early 1980's. 

Over the years I have been exposed to a number application programming environments, each of which handle specific tasks in slightly different ways.  But though there are differences in the programming languages, the process of application development remains the same.  The first step in the process is to determine 'what needs to be done; what is the end-product or goal to be attained'.  Once the goal is determined, the next step will be to determine 'what data, or information is necessary to attain the desired result'.  Once the goal and data requirements are known, there are two distinct approaches that have been taken to accomplish the task of developing the application.

The first approach taken in the early days of application development was the structured systems analysis and design method.  In this model, all of the application requirements were designed up front and the entire system and application level functions were mapped out before any programming started.  The problem with this model was that by the time the design phase was nearing completion, often the requirements for the 'desired result' had changed.  These new requirements would have to be integrated into the original design, which in some cases caused some of the low-level system functions to change.  As a result the application level functions would also need to change, and in some cases the amount of rework was so great that a complete rewrite was necessary.  Unfortunately, many projects were scrapped even before any code was ever written.

To address this problem, a new methodology called rapid application development (RAD) was introduced.  In a RAD environment, a prototype of the end-product (or feature) is developed early on in order to ensure that all user requirements have been addressed.  Often times the user will discover additional requirements once they see what can be accomplished, and these new requirements will be integrated into the working prototype.  This is an iterative process where the end-user and the system designer work together in order to complete a working model that can then be developed into the end-product.  The advantage of this approach is that the customer will learn early on whether their desired result is even feasible, and if so what the cost/benefit analysis might be.

As might be expected, there are downfalls to the RAD model as well.  Probably the biggest problem I've seen with RAD is when the programming language used to build the prototype is not well suited to handle all of the low-level system needs nor the performance requirements of the enterprise.  As always there are trade-offs, but over years of architecting applications I have found the benefits of RAD (now more commonly known as agile development) to be superior to the structured systems analysis model discussed above.  The main advantage that I find with agile development is that it is an iterative process.  User requirements are determined and a working model is developed in a short amount of time comparatively, providing an arena for brainstorming that would not otherwise be possible.

This concept of brainstorming is an important one as it represents a process where ideas can bubble up into the consciousness that would otherwise go unnoticed.  Over time the intuition awakens as this process becomes even more refined.  As a result I have integrated agile development into all of my projects and have benefited greatly from it.  RAD allows me to turn an idea into a working model at a minimum cost!