Tips When Engaging Web Developers and Other Procedures

Code Commenting

All code should have more commenting within it than actually needed.  Some coders will moan but screw them. You need to be able to get other people to be able to understand the workings of whatever you have built and probably at a time when you don’t actually have time, i.e. it has already hit the fan.

Cross Training of Programming

If you have more than one programmer then insist that they are made to understand each others applications.  Do not accept the line that “it’s [insert name]’s code and it’s a mess”, make them follow it and ensure a good level of understanding, consider it a peer review. You never know when one of your coders might get hit by a bus!

Passwords and Server Access

Parts of this may not be needed, but make sure you have an exit strategy for the time when you may fall out with your developer.  Ensure that you know what the passwords are and that they are nicely stored in password class that if needs be you could find them and change them. You also need to keep the keys (or know where they are) to the server. Make sure you know how to get in touch with the hosting company. If you are worried about looking like a bastard boss then wrap this up in “Documentation / Processes”. You may think this is overkill but I have seen instances where partners have fallen out and the techy one has been locked out the true owner and had emails re-routed and lots of other nasties.

Insist, no demand that no one ever logs in as root. It can be dangerous in the wrong hands. Get them to log in via a user name than has sudo access. Sudo can limit all sorts of things so that you can even give user rights to access just certain parts of the system, eg apachectl

Above all, have a plan for when one day you might fall out with one of your developers. I reckon that you could hide a script in the root directory that could be a one sweep password changer which your trusted man could activate when Armageddon comes. Best to stay good friends with this person 🙂

Development Server Environment

Never ever allow development on a live server. If you do you are asking for grief and woe of biblical proportions.  Have one trusted person do the final ftp/ssh to the live server. I have seen many problems, from overwriting a CSS file (gone forever) due to two people editing on a live server to servers being borked by inexperienced unix operation and god awful code. Check out my quick install of a sever.

Test Test Test and Test Again

Generally when a developer says that something is finished and working…it isn’t ready. Get them to test each others applications. You may need a suitably picky person on tap though who can find the flaws. Get them to write them down as they occur, take a screen print of complicated errors and write instructions on how they created the error or problem so that they can be tracked down. One of the best I have seen at this was Doug Scott, who if one tiny thing did not work he would assume the whole app was not working. Very funny to watch the faces of a proud programmer.

Keeping a Clean Ship

Servers can get messy, really messy quite quickly. Quite often it is just laziness and even I have done a few sneaky folder name changes to remove something offensive looking. Certain directories are sacred, under no circumstances should there be junk or test folder structures within the public_html or near there.

 I have seen the following:

public_html1
public_html2
public_html_new

This is a sacking offence 🙂 . In the case above code libraries were even crossing over but only one was the real public_html. It was a real mess.

Don’t allow low level users create new linux usernames all over the shop. Make a clear distinction of where development can be done and stick to it.

CVS

A lot of the problems with coding and software release versions can be prevented by using  a CVS. One that was used to good effect where I once did some work was SVN and Tortiose SVN. This means you can see code develop, rollback when then is a problem, backup easily and much more.

Backups

There is no excuse for not having a backup procedure up and running including documentation. Consider something like reoback. You should actually test the backups too. I have seen a backup reinstated due to corrupted data only for that data to also be corrupted. You need to shelve off data periodically in cases of major corruption.

Backups and disaster recovery is a whole major project, but most important. Media  these days is cheap, a TB for £150!

Remember to keep one offsite at all times, no good if there is a fire/flood/burglary.

Code Libraries and Language Libraries

If you are working on a big application then you need to be able to find common stuff easily. You need OO programming here or at the very least nice functions clearly commented and placed in separate files.

I like to get language libraries created, where all the interaction between the user and the application is installed. So when you see a spelling mistake or error when a interaction has taken place you can get to is easily and change it, as it is a nicely named function (errorMsgUserWrongPassword()).

Avoid inline formatting within code as this gets messy when you want to change something.

Load testing

Nothing like getting a shiny new application working nicely when you alone are using it, so you pass it into 5 mates and it runs like a dog. There are applications to load test (Neoload) which can mimic user actions and can be ramped up. Your coders might cry at this point when they realise that only two concurrent users can log in, but better to find out before the big press launch:-).

Design with Scale in Mind

If you are spending time to build a decent application you are hoping that it will go big. So you need to think big from the start, design the DB as if your application will have all the features you could ever want, even if you don’t build them. You may want to add them one day and nothing makes people cry more than someone who has to rewrite a DB from the ground up when they could have planned for it in the first place.

Can your site handle a FARK, or front page of digg, if not, how can you make it. Consider page caching.

Can the application, if needs be, run separate DB servers or handle load balancing.  I have seen load balanced servers need manual updating of DB’s or some such weirdness and during the “balancing” stage it would write to one of the 2 different DB’s!

Ensure SEO Standards

Before any code is written ensure that the site and application will be both SEO’able and reach accessibility guidelines. It is super easy to SEO to a high level just by having certain things in place like standard headers, titles and page hierarchies. Make sure that you a template that is constructed from easily defined variables, wordpress does it well:

http://codex.wordpress.org/Template_Tags

Have a list of standard SEO errors that must never occur.

IPR Ownership

It must be watertight on who actually owns the intellectual property rights on the application, all it’s code and anything discovered during the build. You don’t want to see your killer application re-launched  by a disgruntled ex employee.