Managing Web Projects #9 – The Development Process
This is the 9th installment of my “Managing Web Projects” series. Apologies for the delay in getting back on track with it but for some reason I’ve been suffering a severe bout of procrastination. Anyway, I digress, on with the show!
As mentioned in my previous post “Managing Web Projects #8 – The Design Process”, design and development can often run concurrently.
For example, you could build the back-end admin system that doesn’t require any graphics apart from a logo that can be dropped in later, or you could write your code to be dropped into a template page, which includes the design, later.
However, before you start to knuckle down with 10 cups of coffee for a late night coding session there are a few things to consider.
Oh what? I’ve waited ages for this, I wanna code now!
Patience is a virtue!
The design of the site can have a great impact on the way that it is coded and even the programming langauge used. Before you rush off and begin merrily banging away at your keyboard, sit down with the designer and discuss the matters that will affect how you, as the developer, will do things.
Some example questions:
- Are there only supposed to be 15 lines of text on that page as the design scamp only shows 15?
- Does the design allow for page scroll or will you have a defined content area in terms of height?
- Is the design a fluid or static width?
- Will it require any tweaks for different browsers?
Of course, the questions you ask will depend on the design, what you are expected to do as the developer, and the Technical Requirements Specification but it’s better to get these questions sorted out at the beginning rather than land yourself with an unimplimentable design – but you sorted that out in the pre-design/development meeting right?
Okay, I know what I can be doing whilst the design is being finalised. Let me at it!
Er, already? I don’t think so.
What languages are you going to be using? Do you have the resources? This in theory should have been sorted out in the [URL HERE]planning stages but projects do have a tendency to creep and a key resource may not yet be available.
The following is more relevant for developers working in groups but all developers should take note of the principals:
- How will you know who is working on what?
- How are you going to implement backups and version control?
- How will you track bugs during production?
- Do you have a code library (if your answer is “No” – set one up now!) if so do all necessary users have access to it?
- What type of development environment are you running and who is responsible for setting it up if it hasn’t been done so already?
- What can you work on and when? Are you waiting for the design or can you just drop the code in later?
- How will you test the finished code?
These are just a few of the questions that are of the utmost importance if you don’t want to get off on the wrong foot. I’ll discuss each of them in more detail below:
How will you know who is working on what? / How are you going to implement backups and version control?
These two issues are actually linked. If you have Joe working on the contact form email code and Frank implementing the email form design, they’re each going to overwrite the others hard written code. They won’t be happy and neither will you!
Some programs (such as BBEdit and Adobe GoLive) allow users to “check in/check out” documents so that they become locked when worked on to prevent accidental overwriting. These programs will usually also save a backup of each version produced allowing to rollback content if required.
This means that you’ll have full backups, version controlling and no-one can overwrite each others work – bonus!
How will you track bugs during production?
This is quite important, not only to note what’ll need fixing when the page/project/section is finished, but also to figure out workloads. You don’t want poor Joe coding the entire back-end of the site and be expected to fix every single bug do you? Make sure you assign the bug fixing fairly and set a reasonable date for it to be fixed.
As a personal observation, it’s also probably a good idea to get a different person to work on the bug fix rather than the person who wrote that actual piece of code. From experience, the original coder (and this includes myself) knows what the code is supposed to do and generally can’t fathom out why it’s not working properly. Use a fresh pair of eyes who will see what the problem is rather that what is supposed to be happening.
Bug tracking can be done using a simple spreadsheet, text file, piece of paper in a binder, a wiki or a more complex “help desk” like solution such as Bugzilla. What ever you implement, make sure it’s quick and easy for users to report bugs or they won’t use it.
Using a database driven bug tracking package also has the advantage of acting as a searchable knowledge base. Users can add their comments/solutions to the bug which can then be searched at a later date, and for a different project. For example, if Joe can’t get his email component to send mail from the contact form he is working on, he can search the knowledge base to see if someone else had a similar problem and what their solution was. This will greatly cut down on development/problem solving time and reduce future bugs.
Do you have a code library?
Every developer should have a reusable bank of cod they can drop into their web applications. This could range from simple email scripts to complex functions and database manipulation code.
Ideally this code bank should be a central repository every developer can access, rather than being developer-centric. Allowing all developers to access this resource will greatly speed up production time after all, there’s no point in spending days re-inventing the (coding) wheel!
One important factor to remember in the reuse of code is copyright. Pay attention to your client agreement/contract as if the contract states that the client owns all source code, unless exceptions are stated, technically you won’t be able to use your “reusable” code in another web application again as your previous client owns the copyright! But hey, you sorted all of this out at the contract stage, right?
Again, from a personal perspective, when developing code it’s best to put reusable code in its own include file meaning that you don’t have to retype it (or copy and paste from your codebank) multiple times.
Type of development environment
Although the programming language and server requirements will have been set out in your Technical Requirements Specification (which you have written, haven’t you?), there are a couple of important points to note regarding the development environment:
- Do all users have access?
- Will it be set up on time?
- Make sure you know who is responsible for it.
- Is a reliable backup system in place?
- Will there be any firewall/access/permissions problems?
- How similar is it to the live environment?
- Are the correct components installed and the same version as on the live server?
- Is the required database installed and is it the same version as on the live server?
- Are the scripting languages the same version?
- Are the operating systems the same version with the same patches/hotfixes?
These may seem like overly obvious questions but I’ve lost count of the times I’ve spent hours working on code for a specific database or component only to find it’s not installed on the live server, and it can’t be installed! (Note that this was the Project Manager’s error, not mine. They’d written it in the TRS but failed to actually check with the hosting guys – doh!)
Also, it’s probably best for all developers to work from one centralised development server. Not only does this help with version control, but all developers will be working in the “correct” environment rather than their own machines which may have different software versions installed and their own particular quirks.
What can you work on and when?
Unfortunately on sites that rely heavily on page design/layout can’t be coded until the final design is completed, approved and templates made.
If you’re in the enviable position of having a completed design before you begin coding, or don’t have to rely on a design template to get going, where do you start? Well, that’s the $64,000 question isn’t it?!
It’s really a matter of personally preference although if you have a website that relies heavily on a database to dump content into the front-end of the site then the logical starting point would be the back-end so that you had some way of inserting your content (and checking it displays in the correct format). Of course, that’s not to say that some front-end work can’t be done during back-end development such as template design for dynamic content to be dropped into later or any static/non-dynamic pages.
The most important factor here is knowing who is responsible for what aspect of development, the expected start and end date and overall project completion date – but that was all sorted out in the planning stage, wasn’t it?
How will you test the finished code?
As a web developer, I feel we’re probably the worst people in the world to test websites.
Huh? That makes no sense!
Think about it. If we have built the website, we will use it (i.e. navigate around it, use the forms) the way that it was meant to be used, rather than the way a “real-world” user would use the site. They’ll not understand links, enter rubbish into form fields, look in the wrong place for things… get the picture?
Secondly, if we haven’t built the site, we’re all to quick to criticise other peoples code – “Oh, I can’t believe you used a table, I would have used CSS there… blah blah” – whether it’s warranted or not! Developers always “know” better than their colleagues and will often look at the underlying code for errors rather than functionality and input issues. Admit it, I bet you’ve done that yourself a few times!
I would come at testing from two fronts. Firstly “employ” an independent tester who hasn’t been involved in the design process. This independent tester will test the site on the development server to the constraints set out in the TRS (or separate testing document) and will check for things such as illegal input on forms that may break the database (don’t you just hate those pesky ‘ ?), how the template works in different screen resolutions and on different platforms and do basically everything a standard user would do “wrong” (but of course they don’t see themselves as “wrong”, it’s the website that’s at fault!)
Any errors will be logged in the bug tracking system and fixed and re-tested before being released to the second phase of testing.
The second phase of testing is a roll out to a “staging server” where the client is able to access and check the site to ensure that it meets their requirements. This will probably be more in terms of look and feel/functionality as opposed to bug testing, but any bugs will be added to the bug tracking system, fixed and then re-tested by the client.
This article has covered the basics of the development process and touched on testing. Testing will be covered in more detail in the next article in the Managing Web Projects Series: Testing the “finished product”.
Don’t forget to check out the e-book version!
- Follow Katy Whitton on:
