6 More Ways to Cut Web Development Time

I’ve just been browsing through Digg and I found two excellent blog posts about reducing web development time.

Firstly there was “10 Dirty Little Web Development Tricks” by Yong Fook. I’m pleased to say that I’m doing most of these in my normal day-to-day development roles, which at least means I’m doing something right!

Secondly there was “10 Ways to Cut Down Web Development Time” on Six Revisions. It too offers some good tips, even if the last one looks like an attempt to make the list items up to a nice, round 10!

Whilst both these posts are excellent, and I strongly recommend anyone who has even a passing interest at developing websites competently to scan through them, I thought I’d add on a few pointers I’ve learned over the years.

Firstly, without wanting to repeat any of the items in the two posts, I want to emphasize a couple of the main points:

1. I could not agree with Yong Fook’s first point more: SVN checkout as the production site. The amount of time this simple act saves is staggering, especially when you are developing multiple sites that may have multiple branches and you’re trying to keep everything up-to-date.

2. Use an IDE. Whilst agreeing with this point wholeheartedly, I thought I’d try and answer Tom’s comment: “IDEs waste as much time as they save. Terrible tip”. It’s not a terrible tip, it is just that IDEs do take some time to set up and get used to. They are not just like a normal text editor, there are normally quite a few things to set up and get working before they really begin to pull their weight and start being something more than, well, just a normal text editor. There is the debugging functionality to get sorted, the “code help” may have to be turned off, the auto complete might need tweaking (but not normally) and the structure of the projects might have to be re-jigged. But once this is all done, these tools become invaluable and indispensable.

Right, now on with my list

1. It must be simple and quick to change what you’re working on

This is related to using SVN as a production site, but slightly different. It must be really simple and quick to switch from working on a development site, to then working on and deploying to the live site. Some of the projects I work on have 3 servers – live, staging and development. The live and staging generally use the same code base, but the dev site is normally a branch which is then merged into the main trunk when it is feature complete. It must be simple for you to switch working from one site to the next.

This means that any configuration files, or caching/uploading directories set up must be outside the SVN so no conflicts happen. If it is important that the staging server and live sites are pretty much mirrors of each other, only with the staging site having a more active code base, then a script should be written to drag any images off the live site to populate the staging site (or visa versa) so when working on it any image problems etc. can easily be picked up on. For instance, if you have the functionality that resizes images, you need the source images on the staging server to check that it is working. (OK, pretty poor example, but something along those lines)

2. Use a build script, on all servers.

Yes svn update is great, but there are many times when it isn’t enough. For instance, the development site is password protected, so the .htaccess file needs a directive in there to initiate authentication. Or whilst the live site will always need to make sure it is displayed as http://www.example.com in the browser, not http://example.com then the .htaccess file needs to have a Mod Rewrite directive in there, but not so for the development site.

For this there should be a very simple build script (I normally use a quick and dirty shell script) customised for each server. My build scripts normally do the following:

  1. Remove the .htaccess file (to stop conflicts)
  2. Update from the SVN
  3. Modify the .htaccess file, adding the authentication, or removing the redirect
  4. Report that it’s done

3. Develop for the server you’re deploying to

This may sound obvious, but it is important to actually develop for the machine that the website is going to be deployed to, hosted on, uploaded to, whatever you want to call it. There have been countless times that a perfectly working site on a local WAMP machine has been uploaded to a Linux development (or even live) server and it has broken due to the different ways the two operating systems handle case sensitivity in file names. Or if the live server is running an older version of PHP (or whatever) than the development server, you find that your whizzy new function doesn’t work. It is such a fantastic waste of time, so know what you’re developing for.

4. Use Virtualisation

In web development you have to do a lot of testing. Yes you can use automated testing scripts like Selenium, and frankly you should, but you should still look with your own eyes to make sure it’s all working correctly – especially with the number of browsers that have to be developed for. Using virtualisation software like Virtualbox, Parallels or VM Ware you can set up a number of virtual computers that between them have all the different browsers that sites have to work on these days, and without having loads of physical machines cluttering up your office.

5. Enable keyboard short cuts

My main operating system now is Xubuntu and it allows for the creating of user defined keyboard short cuts. I can open up my browser, my mail reader, my IDE without having to point and click. Obviously this doesn’t save a massive amount of time, but it is really handy to whip open a terminal and start typing without having my hands leave the keyboard.

6. No distractions!

And finally, if you really want to speed up your development time the there is one very simple thing you can do that will bring untold benefits: Turn off your email, or Twitter, or Facebook, or GTalk, or mobile phone, or whatever. If you allow yourself to work without any distractions, then you will see your productivity rise, and development time decrease.

So stop reading this post and get on with some work!