Thibauld - Imagination and Execution -

Web application implementation step 3: Framework vs Methodology

Now you must be wondering why I'm so skeptical about frameworks... actually, I have nothing against frameworks in themselves (see my post on the subject), some are better than others but generally speaking, they are all useful in some way. No, the problem lies more in what people tend to expect from frameworks. Indeed, a lot of people expect that, because they're using a good framework, they'll be able to code efficiently and deliver a great web app quickly. Unfortunately, this is a wrong reasoning... your coding efficiency depends more on your methodology than on the framework you're using. Just as an illustration, coding version 1.0 of freelance business club required only 3 months, starting from scratch and without using any framework.

The ultimate rule for coding efficiently is the following: first think, then code. I will now explain in more details the methodology I personally use when building web applications. This methodology is summed up in the following schema:

Process listing

This is, by far, the most important step, the one that can save you an incredible amount of time! When you start a project, everybody has a gazillion ideas on the application features: "it must do this, that" "how about this ?" "It would be great if we could do that" "You know what would be great ? this!"... Don't get me wrong, having people brainstorming around the application potential features is great, even essential, and you should write down all these great ideas. But obviously, you won't be able to have all these features for version 1.0.

First, you should translate these features into processes. A process puts a feature into perspective. The question to ask is the following: "To which business process does this feature belong to ?". You'll be amazed eventually at how many proposed features don't belong to any real business process and are, thus, irrelevant to your application. In particular, developers (me included) often think about adding "cool" features from a technical point of view... but each "cool" feature, even the smallest ones, take time to code so it is very important to think about its real usefulness from the end user point of view. Thinking in terms of business processes rather than in term of features is a good method to separate relevant features from irrelevant ones.

At this point, don't forget the "backend" processes, that is, the ones required to run your web application. These backend processes are too often overlooked, which result in people finally spending a lot of energy to administrate their web app. And "no", PhpMyAdmin cannot be your only backend application.

Once you you've listed all your processes, the next step is to break them down in milestones. The most crucial processes will go in the first milestone, the less important ones in the next milestone.... ect... the least important ones going in the "later" pseudo-milestone. At the end of this step, you've got all your processes listed by milestone.

Now, before going any further, I encourage you to perform some research to see, for each process, if there's not an available application/api/webservice out there that you can leverage to help you implement this process faster and/or better. This can be a huge booster and might prevent you from reinventing the wheel (and probably a poorer one).

Maquetting / Wireframing / Prototyping

Now that you know which processes to implement for the next milestone, you need to "wireframe" it (in french we say "maquetter", I'm not sure of the english word for it). What is important in this step is to synchronize everybody on each screen which are to be develop. What's in a screen:

• General layout of the page
• Information displayed
• Links available

To build wireframes, I personally tend to use Impress (the PowerPoint like module of OpenOffice.org) but you can use anything you like, pen and paper are ok too... If you're a Windows user, a friend of mine uses Axure, a commercial tool dedicated to wireframing and prototyping. Once you've got all your screens ready,  you may want to turn them into a real prototype to have your users validate how you will implement the business processes. On linux, I found that such a task can be easily realized with kimagemapeditor: just import screenshots of your screens and define the links between them using html image maps. You'll end up with a static website in which you can navigate easily.

Once this is done, you can have your graphical designer start working to turn these ugly wireframes into art!

URL listing

At this point, once you have all your screens and their relationships setup, it is time to decide the URL of each resource. It is very important to think about your URL strategy beforehand for several reasons. First, as you're building a web application, you cannot ignore Google and need to implement a google-friendly URL scheme. Then, thinking about your URLs help you switch mentally between your user requirements and how you will code it.

For example, in the code architecture I implemented, this step is key as I cannot code anything until I translated my URL scheme in a .htaccess (using the urlrewriting Apache module). This .htaccess determines how I organize my presentation handlers.

Database design

During the previous step, you probably began thinking about the 'objects' you are going to manipulate. It is now time to write it down by coming up with a complete and coherent database design. I cannot stress enough how much database design is key. If you fail here, you'll have to code a lot more than needed. You will not only have to paliate the inefficiencies of your database design by coding more, but you will also have to deal with poor application performance sooner than expected.

Does "referential integrity" sound familiar to you ? it should... Too few people realize how powerful a database like Mysql or Postgresql is. SQL being a declarative language, a lot of developers don't like it much but it's a pity... it can be really powerful and you can delegate _a lot_ of work to your database. Letting your database handle work saves you coding time, and will probably boost your application performance. Database design is a vast subject... If I have time, I'll probably write a post dedicated to it but meanwhile, I encourage you to read this great book : The Art of SQL.

Coding

Now you can begin coding Of course, I also have a methodology for coding. This is good practice to implement process by process (you can parallelize work depending on your team size). The most important thing being what the end user sees in the end, you should start for each process with the presentation layer, then continue with the business layer to finally end with the data layer. To ensure a good level of quality, once you finished coding a layer, validate it using dummy values from the n-1 layer (because the n-1 layer has not yet been implemented). If you follow this methodology, you'll be amazed at how fast you'll be able to develop your web application.

That's all for today, see you next post!