Web Design Industry Blog

Blog Rss Feed

Can you be sure your web designer is doing a good job?

Published on October 4, 2010
Tags: Web Design London

Time and again, we've seen clients who have had a bad experience with their web designer. Sometimes it’s obvious; the web design is broken, the functionality doesn't work properly, there are massive delays on the project, or the website designer just disappears.

Other times, though, things may not be so easy to spot but could have equally serious implications for your web site and for your business.

You run a business though, and you shouldn’t have to concern yourself with what goes on behind the scenes.  So what is it that you need to look out for and more importantly, why?

  1. Poorly written, insecure code. This is the most common problem we find when we’re reviewing code written by other web designers. It you have any kind of database on your site (such as a content management system or ecommerce web site), or any kind of customer login facility, this can be the most serious issue you need to concern yourself with.  Poorly written code can make your site vulnerable to SQL injection and HTML injection attacks which can lead to situations such as hacked, virus-infected web pages being displayed on your site through to far more serious issues such as the theft of customer data – which can also put you at risk of prosecution under the Data Protection Act.

  2. Business logic mixed up with controller code. Code should be written in a structured, layered format with a layer for the database, a layer for the business logic (the rules and functions about how data gets in and out of a database), and a layer for the presentation (what actually gets displayed on visitor’s web browser). Actually, there’s a bit more too it than that, but that’s the core of it in simple terms. Very often, poor programming will mix the layers together which can make management of the code extremely difficult, can make the code unreliable, and can make it difficult to provide fixes and updates to.

  3. Bad coding practices. Code can be written in a number of ways and it depends on the developer’s training and preference as to how they might write individual functions and pieces of code. A developer with a strong background in coding methodology and who keeps their skills regularly up-to-date will generally write code better than someone that may have learnt in a more ad-hoc way and doesn’t continue with any ongoing training. Poor coding practices can lead to the situations mentioned above, as well as poor-performing code that can affect, for example, the speed of page loads (which affect Google positions) or the speed of on-site searching.

  4. Lack of commented code. Generally, good practice dictates that when code is written, each function within the code should be commented. This helps any other developer who updates the code to better understand what the code is intended to do, and how changing it will affect other parts of the website. Lack of comments indicate a lazy approach to coding, and can make it almost impossible for another developer to pick up the code and successfully make changes without having some other documentation (such as a technical specification) to work with.

Sadly, unless you are familiar with code you’re not likely to be able to spot the above four issues so how can you tell whether your code is well written or not:

  1. If the price is too good to be true, it probably is. Don’t forget the old adage that if it’s too good to be true then it probably is. In web design, this is certainly the case. Whilst you may be working to a budget, don’t pick the lowest quote if all of the others are considerably more expensive. If you are going to outsource overseas then do be aware that the majority of poor code reviews that we conduct are from well known overseas outsourcing countries. That’s not to say that every company in an overseas location is incapable – there are good ones out there – but the prevalence of poor coding habits, driven perhaps by the educational process for developers, is higher.

  2. If your project has had problems, get your code reviewed. If you project has been troublesome, running late, or your developers have had problems fixing bugs when you raise them then consider having the source code reviewed by a third party. Very often, there are obvious warning signs such as these that things are not going to be ideal behind the scenes. The sooner in the development process you are able to do this, the better.

  3. Don’t pay everything upfront! It sounds obvious, but it does happen. Typically, you may be asked to pay 30% on project commission, 40% when the beta site is delivered and 30% on project conclusion. Most developers won’t release the full code until you’ve paid in full, which is fair, but you should be able to ask for a portion of the code at beta which can be reviewed by a third party. Then, if problems are found with the code quality you can either ask your developer to rectify them or reach an agreement to close the project off at a discounted total fee and move to another developer who can conclude your project.  It’s worth noting though, that a reputable developer may review your original developer’s code and tell you that you need to start again. This is the worst news to receive, but it is sometimes a necessity to go back to the beginning to get it absolutely right.

If you are currently looking for a web developer to complete your web site because you’re experiencing difficulties with your existing supplier, contact us today for a free assessment and no-obligation discussion.

By Chelsey Evans

Submit Blog & RSS Feeds 
 

Comments

Elite, Manchester

Commented on February 9, 2011

Its a bit of trust and confidence that web designers should show.

Leave a comment

 

Name *:

Email Address*:

Comment *:



Security Code:*
Reset Security Code

 

Follow Us: Follow us on Google+ Follow us on Facebook Follow us on Twitter Follow us on LinkedIn


Disclaimer: The content of this article is provided for information only and do not constitute advice. We are not liable for any actions that you might take as a result of reading this information, and always recommend that you speak to a qualified professional if in doubt.

Reproduction: This article is © Copyright Ampheon. All rights are reserved by the copyright owners. Permission is granted to freely reproduce the article provided that a hyperlink with a do follow is included linking back to this article page.