Modular rapid web application development
While at the KIC, I've been doing contract web development work. The project that I've been developing for has a launch goal of the start of the school year, meaning this up coming September. We are hoping to have a functional, operational verison to display by that time. I hope I can convoy the general size of this project when I say that this is a very signifigant undertaking.
Instead of the traditional development model, we've sort of adapted to a system that is much more simple. All the developers should have a sturdy idea of what the final project will look like. Each person should have a proper feeling of what the project is actually supposed to do. Nothing more is required. The entire process is cumulated as followed:
Firstly, pick a piece of the project that must be done.
Next, just code it.
It doesn't have to be pretty. It doesn't have to be perfect, or entirely bug free. In fact, it isn't much more than prototyping. The one key idea is that it must be modular. The piece of the project that you just developed must be able to slide into the project nicely, and out of the project just as nicely when it comes time to replace your code, and it is always best to assume it will be replaced.
The idea is to create a system that may be quick and dirty, but yet functional. Once things are actually deployed and running, every developer can take a step back to relax and reflect on the system they just finished building. This is when we take advantage of the old programmer saying.
Every good program should be rewritten three times.
However, in the real world, no programming team has the resources to rewrite their entire web application. The key to this development idea is that things are modular, so developers can select the piece of their product that needs the most work and rewrite only that. With a modular development method, anyone can pick a piece, tear it out, rewrite it, and replace the old chuck of code with the new piece without breaking the entire system.
As an added benefit, the technologies utilized in web development are inherently modular. We naturally break our project into backend, AJAX, Javascript, and HTML sections. A separate division could easily be created by separating CSS, templating, and Javascript code into separate files each controlling separate pieces of the interface.
Backend <-> AJAX <-> Javascript <-> HTML/CSS
Of course, as projects scale and teams grow, this model becomes quickly obsolete. Calling it a "model" is even pushing the word, and I don't believe this would function for large sized projects or even medium-sized push-distribution products. However, web products are a different story. The web moves fast, and it can be far too easy to spend more time planning than actually coding.
The beautiful thing about being a web developer is that we can do this, and get away with it! In a world where it takes seconds, and a few uploads, to push a new version of our product to every customer we have, why do it any other way?