So after all of these years of paradigm shifts in the same coding methodologies, same in the sense that they get regurgitated with different names, Agile for instance; we are still seeing far too many applications being launched only to encounter some level of failure, sometimes complete failure.  Those failures typically manifest themselves in two major areas, firstly a lack of key functionality required by users and/or a failure to support the number of users or to scale efficiently when the user load increases.  Capturing user needs effectively is a subject with many volumes written or blogged on the subject.  In my years of developing web applications, I believe the Flip process which came from the FuseBox community was the best attempt there has ever been to create a successful method of capturing user requirements and coupled with DevNotes, allowing user-developer interactivity on a screen by screen basis, there was a potent overall method of getting what the users actually needed without them killing  the project in the process and having them feel involved and happy.  We can debate Agile etc till the cows come home, but Flip with DevNotes was very potent.

The main purpose of this blog post is to lay out, what I believe and have found to be a way to ensure that when an application is launched it will handle the expected user load and will also scale both on a single server and also across multiple servers as the application load and availability needs increase.  This sentence contains an essential state of mind which I believe we all need to subscribe to as application developers, managers etc.  That is that the application we are designing, engineering, coding etc will need to run on multiple instance/servers/locations, we need that mind set from day one and at all times, ongoing.  With this in mind we should never hard-code anything into an application that is specific to a single server/instance; drive paths, server/instance names, IP Addresses etc.  Believe me, if we don't follow this simple rule we will hit a brick wall of hurt sometime in the future, that is assured.

One other major point I want to address here, before launching into my main thrust.  With the ever increasing use of Cloud Computing comes a very dangerous mind-set, in my opinion.  That mind-set is that we do not need to pay that much attention to scalability in the development phase of our application lifecycle as we can simply use the "on demand" characteristics of Cloud Computing to scale as we handle more load.  Any one reading this blog post who has worked with shared ColdFusion hosting will know that there is no horsepower nor server anywhere that can make up for badly written code.  In Cloud Computing that gets even worse because if the problems in the code relate to hardware items, reading-writing files to a hard drive, interacting with physical network devices, such as NIC's.  The reason is that these items are not accessible by us, so if you are  contemplating Cloud Computing, it is even more critical to follow these points below.

With that in mind we will now discuss the simple principles to follow to ensure all the applications we design and write will operate efficiently from day one and scale effectively as the need arises.

APPLICATION LIFECYCLE STEPS

Step 1: USER NEEDS - WIREFRAME/PROTOTYPE - Capture all user needs before starting to code and get them to sign off on the fact that you have captured what they need.  Also and ideally, give them an adequate feedback mechanism which is dynamic. As I mentioned above, Hal Helms created a construct in ColdFusion called "DevNotes" which when combined with a WireFrame presented a very potent way to glean feedback from the users before coding starts.

During this main functionality gathering phase we use two major "sub phases".  The first is to create a click able "wireframe" with no graphics, I stress this because some firms call the look and feel phase (prototype) the "wireframe" phase, in our opinion, a wireframe should have no graphics, but should be realistic model with click-throughs.  Once the client has approved the click able model we can then add graphics to create a prototype.  Once the client has approved the prototype we then move to the development phase.  

Step 2: DEVELOPMENT/UNIT TESTING - In our shop we develop locally and each developer has a developer edition of ColdFusion and any other copies of things they may need, a database for instance. The main point is that every developer is independent and can function from wherever they may be; we are fanatical about telecommuting for both developer life-style and ecological reasons.  No code can be marked to go to Integration Testing until all unit tests complete successfully and we are not just talking about unit tests as in OO-CFC constructs, we mean all code functions without breaking on the developers local system.

Step 3: DEVELOPMENT/INTEGRATION TESTING - Here we take the code from all developers and move it to a central development server and test the whole application to make sure that code from one developer does not break code from another.  If any code does break it is sent back to the original developer to be fixed and this iteration continues until all code in the Integration Testing environment functions without fault, at which point it is moved to QA-Load Testing.

Step 4: QA-LOAD TESTING - This is the most often missed phase in application development and it is a critical one that should never be missed; in fact almost all clients we have helped in our troubleshooting practice have problems because they did not load-test the application.  We advise and practice load testing to at least 150% of the expected load and we also get the client to state what the minimum acceptable page response time is.  The application should not be moved to production until it has passed all load testing which means it is responding to the required client page response time at 150% of expected maximum load.  Once again code is iterated back to developers and back through Unit Testing, Integration Testing and Load Testing.

Step 5: PRODUCTION - After following the first 4 steps of the application lifecycle and only after these have been passed, we are now ready to deploy the application to Production.  There is sometimes a separation between Load Testing and QA where the QA environment is a direct copy of actual Production, this is an additional step which is not necessary but nice to have.  

We can categorically state that if this simple Application Lifecycle methodology is followed, the resulting applications will perform as needed in all required environments.  

One very important last point, if Cloud Computing will be the eventual platform, the Integration and QA-Load Testing must be carried out on the Cloud Computing platform to be used.