Building a Website - Part 2
11 October 2011
In part 1 of this multi-part series we looked at the importance of design and planning when embarking on a project, whether it be building a house or building a website.
In part 2 we look at the importance of laying a good foundation before tackling the rest of the project.
Although a house's foundation is not seen, it is fundamental to the structural integrity of the building.
A website's foundation is no different.
A house's foundation serves several purposes.
It provides strength for the rest of the structure and allows the house to cope with all but the most violent of storms.
When designed carefully, it will also allow changes to be made to the house without putting the whole structure at risk.
For example, if you are building a single-storey house but you think there is a strong chance that you will add a second storey later on, it is a good idea to build foundations that are capable of supporting a two-storey house.
It will be a lot easier than trying to reinforce the foundations later on!
A website's foundation serves similar purposes.
When carefully designed it too will cope with the storms of change, allowing even large alterations to be made to the structure without causing the whole website to "fall over".
We have worked on projects where a website (or other software program) has been given a substantial makeover and the underlying layers have remained mostly intact.
In these cases the website's foundation was robust enough to cope with new features and enhancements without detrimental knock-ons to the rest of the application.
It is important to define what we mean by a website's "foundation".
The foundation of a website – or indeed any software project – is not the bottom tier of a multi-tier design but rather the building blocks that all the tiers rest upon.
These building blocks include the overall architecture, the standards and patterns that the development team must adhere to, plus any common or "helper" functionality.
A website's foundation may grow and change over time, but it is important not to abuse this flexibility.
Careful thought needs to be given to the foundation up front.
Many software projects start out with idyllic statements such as "we can rework the data access layer in phase 2", but be warned: unless you are engaged in a carefully managed iterative project, you will rarely have the time to redo your initial work.
What you start out with is likely to be around for the lifetime of the project, so make sure it is built on a solid foundation.
We have noticed that there is a tendency, especially amongst junior developers, to skip the process of laying a good foundation.
These developers jump straight into building the business logic layer, the data access layer, the front-end, and so on before defining the project's general architecture and standards.
They usually cite that their approach is agile or extreme when in fact they are unwittingly becoming cowboy coders, a style ill-suited to most development projects.
We saw the effect of this recently in a project where some of the developers started working on the UI while others started working on the business logic and database access layers, and all before there was any discussion about standards or architecture.
It did not take too long before these 2 groups realised that most of their development iterations were spent reworking their code so that their layers could "talk" to each other, and the project was going nowhere fast.
Eventually the project manager stepped in and made both groups take a step back and define some standards that all future iterations could use and build upon.
Although this took place in a project employing an iterative methodology, we have experienced this gung-ho approach with other software development styles as well.
Although many projects start off with concept sketches of the UI, navigation, site structure, database design, and so on, we cannot stress enough the importance of laying a good foundation at the outset.
Any seasoned software developer will admit that all too often shortcuts are taken, and that these shortcuts cost in the long run.
We have seen far too many projects suffering from not having standards, guidelines and other foundational issues decided at the outset.
One example of many that we could quote relates to a reasonably large project that we encountered recently.
An agile methodology had been employed, although this example could be found in just about any development project, regardless of the methodology used.
The project's business manager decided that the date format used throughout the application – including the reports – needed to change from dd/mm/yyyy to d mmm yyyy.
Only then was it discovered that different developers on the project had not only used different date formats but they had also implemented their own standards.
Some developers were able to quickly change their code to implement the new date format, but for others the correction involved a lot of searching & replacing and a lot of tedious opening & closing of files due to the nature of their reporting tool.
The development team has since created guidelines for formatting dates, times, currencies, and so on, and has created a set of standard controls (for their web application and their reports) that read format settings from a central repository.
In the next part of our series we explore the structure of the website.
Back to top
Add a Comment
Be the first to comment on this article.