5 Tips for Hassle-Free Custom Website Development

• Posted by:
• Olly Lennox
• No Comments

If you are about to embark on a new custom website development project then here are some tips from the development gurus at Lennox IT to help your development run smoothly

 

1  Build from an existing a platform (don’t reinvent the wheel)

 

No matter what technology you use –PHP, ASP.NET, Ruby, Java, etc. – there are very few occasions (read NEVER) where you want to start from a blank canvas and build your web application from the bottom up. Why? Because every web application shares common features; whether they be navigation elements, banners, login/registration forms, or just basic responsive layouts. Recreating all these things from scratch takes time and it is time which could be better invested in developing the killer features which will sell the application

Instead of reinventing the wheel, look for an existing CMS platform (or other frameworks/technologies) which you can leverage and build upon. For PHP there are hundreds of choices from WordPress to Joomla, Concrete5 and beyond. For ASP.NET there is DNN, for Ruby and Java I’m sure there are solutions if you Google for them. Also you needn’t stop at CMS platforms. Perhaps there are similar applications to the one you are developing which can be customized to suit your purpose, think outside the box and see what’s out there before you start coding.

 

2   Create clearly defined checkpoints for the project

 

The biggest threats to any new development project are feature creep and shifting goalposts. Most clients are not purposefully trying to make your life hell; they are simply ignorant of the development process and find it hard to understand why “moving that button from the top of the screen to the bottom” is really that difficult.

In order to minimise these kinds of problems it is important to spell out in black-and-white what you will be delivering at the start of the project and create a series of “checkpoints” where a specific feature or aspect of the project will be demonstrated to the client. It should be made clear to the client that (whilst you will make every effort to see the project through) both of you have the option to walk away after a checkpoint if there are major problems with the project.

Each checkpoint will be costed separately and the client should be invoiced after each one is reached. If the client wishes to make major changes following the demonstration then you can make changes to the remaining checkpoints accordingly or even scrap them all create a new series of checkpoints for completing the project.

By breaking the project up into smaller chunks it become much easier to manage and to cost effectively. Regular meetings/demos with the client will also mean that the project you deliver is in-line with their expectations and they ultimately receive the application they are paying you for.

 

3  Write as little code as you can

 

When you write bespoke software for a client you should think of each code file you create like a small plant that you must take care of. Write a few hundred lines of code and going forward you might have two or three plants. No problem, you can water them all in less than a minute and beyond that they don’t require much maintenance.

Write a few thousand – or even million – lines of code and suddenly you are looking after a small garden centre and you whole life is consumed with watering, weeding, repotting and tending to your crop. Has this metaphor gone too far?

The point is that even the best code requires maintenance and the more code you create the more maintenance there will be going forward. Making changes and adding features will become laborious and costly to your client, the application will start consuming hours and hours of development time to fix bugs and to optimize. The needs of the software will start to dictate the business rather than the needs of the business dictating the software.

Write less code and your system will remain agile, flexible, and manageable which will make both you and your client very happy.

 

4  Only code what you need to solve the requirement

 

Imagine this scenario:

You have a function in your application which needs to be secured so that only certain users can access it. You start building the mechanism for this but you soon realize that perhaps other functions in the future might need to be secured in a similar way and so you step back and start creating a more generic system. As you are building this system you consider the type of functions which might need to be secured and you create a small library which can handle different functions and can be adapted to fit different security scenarios. The end product is elegantly coded and packaged up nicely so you could even reuse it for other projects.

Sound familiar?

Whilst the solution above might seem elegant and “good technique” it is actually very detrimental to code this way. Firstly, we’ve gone against tip number three and wrote more code than we really needed to write. Secondly, whilst we might have produced some elegant code we did not need to produce it in the first place. The requirement was just to secure this single function in the application and that’s all we needed to do. If a requirement appears in the future to secure further functions THEN we can start thinking about our neat solution but for now just solve the simple task in front of you. Potentially this generic library we have written will never be used again and all the additional functionality we added was just wasted effort.

 

5   Create a Test Plan

 

If you are a freelance developer or part of a small development team then chances are that you don’t operate a formal test pattern and most of the testing is performed as part of development process or in a quick testing session before you submit the code to the client. In smaller systems you can sometimes squeak through with minimal testing like this but an application doesn’t have to grow very big before this kind of testing becomes woefully ineffective.

Before agreeing to any development schedule with the client we strongly recommend that you cost in time to create a written Test Plan which covers every web-form and web-function in the application. The Test Plan doesn’t need to be 100% exhaustive like it would be in a large, commercial-grade application but it should cover all the main functions and include some tests to cover malicious data input like SQL/Script injections.

Often you will find that the simple act of creating the test plan is enough to uncover a large number of bugs and then once it is complete you have a formal way for both you and your client to test the application. This not only helps testing different use-cases (like IPad, phones, different connection speeds) but also helps to spread the burden of responsibility between you, the developer and the client so if they are too lazy to complete the Test Plan themselves then you cannot be solely to blame if bugs are found in the live system.

 

---

We hope you enjoyed this article. If you need help with a custom development or would like more information then contact us