As developers, we are often rewarded with praise (or more) for turning new features around quickly.  If your company estimates that a particular feature will take eight hours to write, and you take only four, the company’s making a tidy profit, you can move to the next item in your schedule more quickly and everyone is happy.  This is all very well, so long as that feature has been written properly and in accordance with your company’s general approach; everything ranging from naming conventions right through to the organisation of the filesystem.  If it hasn’t been written properly, then you have incurred technical debt, and at a point in the future either you or another developer maintaining your code may need to spend more time writing a feature or changing your feature than anticipated.

This can cause all manner of problems.  When you come to develop on from your last feature, you might estimate that another bit of functionality will take 8 hours to write.  However, when trying to hook in to the existing feature, you discover your technical debt, and end up having to refactor the existing code to allow you to do what you wish.  This might take another 4 hours.  This might not seem to be a disaster; after all, you were 4 hours up on the first feature, and we’re just back where we should be now, right? Wrong! It is important to remember that managing our time isn’t  just about managing the absolute amount of time taken, but keeping to schedules.  The 4 hours it takes to sort out the mess in this second round of development delays the next item in your project schedule, which might result in a disappointed client.

In my opinion it would have been better to take the full scheduled 8 hours in the first round of development and avoid the unexpected hold-up during the second round of development.  The 4 hours in the first instance are less expensive than the 4 hours in the second, as they’ve less of an effect on surrounding projects & priorities.

The trouble is, at the time the new feature is written, it can be difficult for someone non-technical to tell the difference between it having been done quickly and it having been done properly.  In fact, from an end-user’s point of view, the system can look absolutely identical.   So, given two developers, one who can turn the feature around in 4 hours, and another who takes twice as long at 8 hours, which will the project manager or client be more happy with? My money would nearly always be on the 4 hour guy. But long term, the 8 hour guy is actually going to be less expensive to run, or will at least facilitate more accurate estimates and quotes on the same system in the future.  The problem is, as developers, we need to resist the temptation to be the 4 hour guy. The short term praise can be addictive and it’s understandable why it seems easier and more tempting to do things as quickly as possible and worry about the consequences later.

What I’m noticing is, in 2008 I WAS the 4 hour guy. I was turning around features faster than other people had in the past, and grew a reputation for being quicker.  While I was quicker at the time, now, 4 years on, when I’m revisiting those sites and starting to improve or extend them, I’m paying off my technical debt with ‘expensive’ rewriting and refactoring.  So now I’m in the position where I am expecting the implementation of a change request to take a given amount of time, but on loading up the project and seeing the way it was written in the first place, the implementation is taking much longer.  This extra development time is difficult to explain and to justify to those responsible for project scheduling, and is something that I’m going to really strive to avoid in the future, even if it does seem to take me slightly longer to develop new features than before.

It seems sensible to finish this post with one of the more famous quotes about computer programming. I’m sure you’ll have read it before…

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live

Trust me, it’s bad enough even if it’s YOU that ends up maintaining your code!

Tip: Have your own work space or room

In our house I am fortunate enough to have reserved the ‘box room’ bedroom for the sole purpose of serving as my office.  This gives me an opportunity to enter ‘a work environment’ and close the door on home (and vice versa at the end of each day).  This focuses the mind on work matters and keeps me from being distracted by the massive amount of DIY work that remains incomplete in our house at the moment.  I recall reading articles before I asked for this arrangement with regards to habit fields, and really am a believer in this concept.  I think I would find remote-working so much more difficult if I had to sit somewhere that also served as a relaxation area.

Tip: Set up your working environment properly

Set up your working environment as if you were in an office for a company.  By this, I mean everything; ranging from the bare bones of your work environment to your software setup.  Actually pay attention to health and safety regulations with regards to monitor and keyboard/mouse use; make sure your chair is correctly adjusted (and is adjustable at all! Don’t work on a dining chair!) – in my early days as a freelancer I used to sit on a non-adjustable chair for about 5 hours a day and ended up needing physiotherapy on my lower back as I was in utter agony.

Try not to compromise on your software setup either.  Install the same FTP client you use at work, and configure your IDE or text editor in the same way as your work, including indentation and layout settings; it’s amazing how a little effort to get the environment consistent can make your life so much easier.  My advice extends to, if possible, having a computer for work and a laptop for pleasure.  This further extends the separation of work time and play time; if this is financially not viable then a good compromise is to have two users on your desktop machine; one for work and one for personal use.  I’ll bet your bookmarks for work in your bookmarks toolbar are substantially different to the bookmarks for home in your home bookmarks toolbar!

Keep work and pleasure separate in your software environment too

Moving on from that point, I used to have all of my bookmarks for freelancing and general interests in one bookmarks toolbar folder, meaning BBC News was mixed up with the PHP Manual and a bookmark to my phpmyadmin directory.  This made it too easy to see the BBC news bookmark and check the news for 5 minutes.  5 minutes turns in to 10, in to 15, etc.  Now, I keep my bookmarks separate, by using different browsers. I use Mozilla Firefox for work; and Firefox only has my work bookmarks in it, and I use Google Chrome for pleasure; this has my personal bookmarks in it.  Largely I won’t even use my desktop PC for ‘play’ or ‘relaxation’ and try to reserve that stuff for my laptop.

Don’t get work done in your house when you’re supposed to be working

For the first two days of the remote working arrangement we had ongoing building work.  It is very difficult indeed to get good runs of concentration with the noise, and interaction with the tradesmen.  If you’re having any considerable work done to your house my advice would be, if possible, to go in office for that period.  It’s much quieter and you’ll be much more productive.

Communication

Assuming you are moving from an office environment, you will be used to being tapped on the shoulder and asked questions, and being asked for updates on the state of work on a fairly regular basis.  Though these distractions are often labelled unnecessary and irritating, they naturally lessen in frequency if you’re not in the office.  This doesn’t mean that you should make yourself completely impossible to contact!  I ensured I invested in an unlimited call plan on a home number so that I can call the office as frequently as needed to ask questions to which I need immediate answers, and so that the office have a reliable line on which they can contact me.  Thus far I have more than made good use of the phone line!

Your project manager will largely appreciate frequent, detailed updates of your progress.  There’s nothing worse than having a developer working for a solid few days with no good indication of where they are at with a project.  It’s good to say “all’s going well and we’re on time” and it’s responsible to inform if you’re having difficulties and look to be struggling to deliver for the target time.

Work Time

Something said fairly frequently to me is “oh so you can work whenever you want then”.  I’m not sure that this is entirely true, and my advice would always be to try to be at your desk between the hours that your office would normally be open (in my case 9am to 5pm).  This means:

• You are contactable via email and on the phone all day, should you be needed.
• You maintain a fairly normal working life and have similar spare time as other people (provided your friends work normal hours!)
• You are guaranteed to put in the required number of hours per week.

Quick advice for those who do freelance work alongside a full time job

• The hours of 9am – 5pm are strictly your company’s time.  Make your freelance clients aware of this. Break the rule for noone.  In my opinion, to freelance when you’re being paid to work by someone else is criminal!
• You will find it much more difficult to motivate yourself to freelance after having spent 8 hours each day working in your own house (I used to find working 12 hour days fairly easy if 8 hours were in-office and 4 hours at home).  My solution to this is to work in my office for work, and to move to the sofa on a laptop to freelance.  This does break slightly from my laptop == pleasure rule but at least gives me some separation in terms of the type of work I do!

Summary

Overall, it took me a week or two to get in to the swing of working remotely full-time, but I’ve got there now, and it feels good! I get distracted a lot less on an hour-by-hour basis and feel that I get more done in terms of pure development, and also the three segments to each working week really help me with maintaining my productivity at a high level right from Monday morning to Friday afternoon.  For any employee with the option of working remotely: give it a go, but only if you can separate work and home properly!

I thought “someone else must have had this problem”, and if they hadn’t, I was going to write a Firefox Add On to help maintain productivity by blocking distraction web sites. But, alas, someone has beaten me to it! I have found and installed the LeechBlock Firefox add on and it is fantastic. I’ve added my favourite sites to a list of sites to block at any time that isn’t a break time (so here, 9-11, 11.15-1, 1.30-3, 3.15-5) and it’s proven very effective.

On the command line interface, assuming you have wget installed, type:

wget -r ftp://USERNAME:PASSWORD@mysite.com/

Hit enter and wait while it retrieves everything for you.

I did it this way because I didn’t want to download 4gb of data to upload again, so ran this command direct from the ‘production’ server with its stupidly fast internet connection. Hours and hours saved!

In ‘the olden days’ when processes such as updating your Facebook status or posting a tweet were done through bog standard HTML forms posted by the browser to a new page request, it didn’t matter when the page I was posting to didn’t get posted to fully, or didn’t respond, because I could hit refresh (or press the submit button again or whatever) and the request would be resubmitted.

Some web developers (myself, at times, included) HATE impatient users who will press buttons twice or refresh the page because it’s taking too long. In a lot of apps this means that the action is applied however many times the button is pushed (e.g., two or three orders are placed instead of one). But the reality is, sometimes there is a genuine need to refresh or resubmit, because nothing is *ever* going to happen with the first request that was sent. This could be due to an internet connection problem or a server-side problem.

Now, more and more web sites seem to favour the “no new pageload is necessary” approach which, in itself, I do not have a problem with – at all. What I do have a problem is is when the developers choose to disable the submit button once I press it – permanently. Because if nothing happens for 2 or 3 seconds, I am pretty damn sure that that status update or tweet is never going to get posted. What I would like to do at this stage is to resubmit the request. But at this time, there is no easy way to do this:

• I have not requested the page in a traditional sense in the browser, so I can not push the ‘refresh’ button; that would reload the whole page and typically delete the tweet or status update that I have written.
• The submit button for the form is permanently disabled, so I can’t press it again to submit again.

Even if the JS implementation gracefully degrades (e.g. if I have no JS support I get the “old fashioned” style normal form), this situation occurs for people with JS enabled. Just because a user has JS enabled doesn’t mean that their web connection is faultless or that they won’t need to push that submit button twice!

I was trying to think of a way around this issue that doesn’t require scrapping the AJAX submission all together, and came up with only one potential solution, which is to disable the submit button but only for an elected period of time (say 2 or 3 seconds), so that if the request doesn’t get responded to in that time, the user is given an opportunity to re-submit.

Anyone else’s ideas of how to work around this problem would be gratefully received through the comments section; I don’t want to write software that frustrates people in the same way that this frustrates me!

The main reason for Javascript being used to progressively enhance the user experience rather than be a fundamental ‘requirement’ is cited as making the site accessible to as many people as possible. Importantly, many mobile devices don’t fully support Javascript (Smart Phones tend to, but I’m talking true mobile phones here) and screen readers certainly don’t support Javascript. Realistically, the percentage of visitors falling in to the ‘browsing on a mobile device’ or ‘using a screen reader’ will be low, and often low enough for a client (or yourself) to make the judgement “we’re not going to bother”. It is important to consider that there are advantages to graceful degradation other than making the site as accessible as possible:

Google, Bing, and A.N.Other search engines – search engine spiders are still fairly basic creatures. If your site navigation doesn’t load a new page but instead loads new content in using Ajax when you click the ‘About’ link, how are search engines going to find and index your ‘About’ page content if the site is not navigable without Javascript? It’s quite simple to make things like this degrade; if Javascript is disabled the link should go to index.php?page=about rather than nowhere. Importantly, many clients think that google is the most important visitor; if they’ve forced you to put lots of keywords at the bottom of the site despite your pleas for them not to then they wouldn’t be very pleased to find out that the search engines can’t get any further than your home page.

Application Design – Designing the application so that it works without Javascript and then adding Javascript afterwards often makes the system architecture much more understandable and ‘rigid’. In fact, if done correctly, this can speed up the Javascript implementation process. Looking back to our previous example, index.php?page=about will load a completely new version of the page with header, footer and all the bells and whistles. How about, if you click the ‘About’ link with javascript enabled, it will load index.php?page=about but through AJAX? Using HTTP_X_REQUESTED_WITH we can detect that it was requested through AJAX and serve just the ‘meaty’ bit of the page; ie the content that is changing, rather than the whole page. Does this really add much time to the development process? In my opinion, no it doesn’t!

Of course, the user experience will not be identical without javascript, but in my view it is still important to support users with no support for the language on their device, or even those that choose to browse without it. It is my view that you can treat support for when Javascript disabled in the same way as many designers treat support of Internet Explorer 6: The site should work, but it doesn’t necessarily have to be perfect. Sticking to this general guideline will not add huge amounts of time to the development time of a project, and if it does… you should take a look at how the system is designed, because it really shouldn’t.

Explaining and justifying your decisions

At the most very basic level, take this bit of code for example:

ksort($files);

To most PHP developers it is obvious that this bit of code sorts the $files array in key order. But it is not obvious to any PHP developer *why* I have done this. Adding a comment to say what I am doing and why would help speed up the recognition of what this code does; but more importantly, explain why this code is here.:


/**
* Sort the $files array in Key order. We want them displayed on the
* page in added order, and the $files array is not necessarily
* sorted in that order before this stage.
*/
ksort($files);


Using code comments as a tool: Autocompletion

There are other areas of an application where documentation can be even more useful. Modern Code Editors and IDEs will read what are called ‘docblocks‘ at the top of class, method or function definitions and add the information in the docblock in to your autocomplete prompts. So how do these docblocks work?

Docblocks are generally in this format (opened by /**, closed by */, with a * at the start of every line inbetween) and always apply to the next uncommented line of code. In this case, the line of code beginning with $page_posted_to = is documented by the docblock above.:


/**
* Determine if the page has been posted to with an action.
*/
$page_posted_to = (array_key_exists('action', $_POST) && !empty($_POST['action']));


Within docblocks you can contain ‘tags’. These ‘tags’ begin with an @ symbol and are often read or interpreted by documentation generation utilities or IDEs/Editors for autocompletion. A comprehensive list can be found on the Wikipedia page for Docblocks. Using these tags can encourage you to include information in your documentation that you might forget to include normally, ie the expected data type of function parameters.

At it’s most basic use, docblocks usually look something like this when describing a function or method:


/**
* This function adds two values together
* @param int $a The first value
* @param int $b The second value
* @return int The value of $a + $b
*/
function add_together($a, $b) {
return $a + $b;
}


As you can see, including these docblocks explains in plain english what the function does, what parameters it expects, and what it will return. This can save the next developer that reads your code tonnes of time and headaches, but most importantly of all, will make your code editor or IDE (if it supports autocompletion and docblock parsing) much more intelligent when it comes to helping you call your own methods or functions.

The idea of the ‘architect’ of this system was that any interaction with databases or storage of data; ie the models; would be shared in the central library.  This would mean that changes such as the one I worked on with is_deleted = 1 would be simple and made in one place, and one place only.  A true implementation of the ‘Don’t Repeat Yourself (DRY)’ principle.

The nature of this platform is that it is exactly that. A platform.  This typically means that no two implementations of the platform are identical, so to speak.  The platform is built upon and ‘extended’ to do what the individual customers want from their online shop.  This sometimes means that custom product ‘getter’ blocks of code are written.  Often, the ‘quick and easy’ approach had been taken with these , and they had simply been added as standalone functions in the individual project’s library, called things such as getAllProductsFlaggedAsSpecial()  This obviously meant that when I implemented my is_deleted changes in the central library, and wasn’t aware of the custom nature of these custom product selectors, the sites that used those custom product selectors continued to display deleted products.  Big oops!

This now means that I will need to go through the individual implementations of the platform, search for any custom product SQL that is being built, and add the AND p.is_deleted = 0 in to them.

This whole problem got my thinking about how I would approach this issue (The need to build custom product getter functions in individual implementations of the platform), and here’s how I think I’d do it.

I think I would ensure that all custom product getter functions were in fact methods in an extension of the main Model class that then called a buildWhereClause method that added any global product SQL (eg AND is_deleted = 0) in, like this:


class Model_Product extends Base_Model {
...
function buildWhereClause($sql) {
return 'WHERE p.is_deleted = 0 AND '.$sql;
}
...
}



class MyShopNameModel_Product extends Model_Product {
function getProductsFlaggedAsSpecial() {
...
$sql = "SELECT * FROM product ".$this->buildWhereClause('is_special = 1');
...
}
}

Essentially, what I learnt here was that the developer to begin with that wrote these ‘quick functions’ saved his or herself half an hour or so, but cost me (2-3 years later) a fair amount of time in debugging.  I think this is evidence that coding things the quick way and implementing a fast solution is often a false economy, and someone later in the life of the software will have to spend the time saved (and possibly more) to work around the disadvantages of the quick approach.

• HTTP requests are expensive in terms of time.  Reducing the number speeds page load time.
• Browsers can – and do – cache effectively.  Inline CSS and Javascript can’t be cached for later page requests.
• Images can be optimised on the web without any major loss in visual quality.

Javascript Files

Minify Them!

Firstly, remember that if you are including libraries such as jQuery, there are a few ways in which you can do so.  They offer a “minified” or “compressed” version, which is at least half the size in KB of the uncompressed version.  Given that you are extremely unlikely to need to ever modify the jQuery core, I don’t see any argument for including the full version of the library, and would choose to include the smaller, minified version every time.

If you have your own javascript files that are particularly hefty, you can minify those for production sites too, by using tools such as JSMin.  The only problem with doing this is you tend to need to maintain two versions of the file.  The minification process tends to be irreversible so you will need to keep a “development” copy of the javascript, just in case you need to make changes or additions in the future.

Use a Content Delivery Network for your javascript libraries!

If you want to go one step further, you can include libraries such as jQuery from “Content Delivery Networks”.  Here is what wikipedia defines a CDN as:

A content delivery network or content distribution network (CDN) is a system of computers containing copies of data, placed at various points in a network so as to maximize bandwidth for access to the data from clients throughout the network

Put simply, CDNs are probably much more capable of delivering the javascript files to the web browser accessing your page quickly and reliably than your own server.  Additionally, remember that this means that the CDN is taking some of your bandwidth costs away – at least 50kb per new visitor.  An additional strange secondary advantage is that it is possible that the user has previously visited a page including the javascript library from the same CDN earlier in their internet browsing session, so it will already be cached in their machine, and will not need to be loaded for a second time.

If you are looking for a quick link to the Google Javascript CDN,  you can access it here:

http://code.google.com/apis/ajaxlibs/

Include them only when they are needed!

Imagine that you have a “google map” page on your web site that integrates with the Google Maps API.  You have a fairly chunky 15kb Javascript file that handles your personal Google Maps integration, as well as including Google’s own API file for the maps.  Why would you want this javascript on every page of the site?  A lot of web developers and designers are guilty of putting the javascript in every single page of the site, which means that the request and corresponding bandwidth associated with the maps integration would be used even if the visitor never viewed that area of the site.

Images

This section is going to be quite short, as it isn’t really my department, but my main understanding is:

• Adobe Photoshop has a save for web feature. Use it.
• Application specific META data is not needed in images on the web (I understand that Adobe Photoshop again can be a devil for this). Remove it if you can!
• If you have “hover” states on buttons or navigation items, use CSS Sprites rather than two separate images.  The reasons why are explained in the link supplied, but mainly revolve around making the hover work immediately, and reducing the number of HTTP requests.

CSS

There are two situations here, really.  The majority of the time, most of the CSS will be used on all of the pages of the site, so it makes sense to make this one external cacheable file.  It is important that the CSS isn’t included in <style type=”text/css”></style> tags in the document itself, as this information is not cacheable and will be individually reloaded on the following page.

A lot of sites will include two or three CSS files. One for the site itself, and one for a plugin such as “lightbox” or “slimbox” or something similar.  If lightbox/slimbox is used on most pages, why not combine the CSS files in to one slightly larger one?  This will reduce the number of HTTP requests and put all of the CSS in to a single cached file.

There is an argument, also, that if there is a particularly complicated section of the web site that takes up 10kb of a CSS file all by itself, then that 10kb of the CSS should be split out in to a separate css file and included only in the complicated section, where it is needed.  This kind of optimisation will need to be assessed on a per-case basis!

Finally, remember that css itself can be written efficiently.

Compare these two blocks of code, which do the same thing, and you will see what I mean!


margin-top: 10px;
margin-bottom: 15px;
margin-right: 5px;
margin-left: 2px;



margin: 10px 5px 15px 2px;

In conclusion, the steps above often take less than an hour to implement on a well built web site, and can save a couple of seconds per page load, and a fair amount of bandwidth costs.  With google’s recent introduction of a small focus on page load time in terms of a web site’s ranking, these kind of improvements have more benefits than just making the site appear faster, and are worth paying some attention!

I have worked for both technical and non technical people, and can say that it’s not only whether or not the app is finished that is judged based on the quality of the UI.  A more important factor that is judged is the productivity of the development team.  If you are a developer (which you might be if you’re reading this blog), you will know that writing models and controllers is particularly time consuming with little “real time” reward – that is,  people who aren’t programmers can’t see and don’t understand the work that you have put in.  Sometimes, this can lead to these people thinking that the programmers are doing nothing but twiddle their thumbs and get excited about charsets, or whatever it is programmers do.

Unfortunately I don’t think there is a lot that can be done about this, other than perhaps using these two useful analogies.

• Writing an application is like building a house. The expensive and time consuming part is the groundwork to prepare the site, the digging of the trenches for the foundations, and the laying of those foundations.  During this time the client thinks that you’ve just made a big mess and spent lots of their money, and they haven’t got anything resembling a house to show to anybody.  Additionally, if the foundations aren’t laid correctly, the reset of the building will be more likely to fail.
• An application is like a car.  It doesn’t matter how much time the engineers spend perfecting the handling and power delivery of the vehicle.  If it doesn’t look nice, the majority of people won’t like it, and even more people would decline the opportunity to buy it.  The engineering team needs to be backed up by a telented designer to make a successful product.

The judgement of quality or completeness of an application makes it difficult as a developer to put together any kind of portfolio.  You want your portfolio to *look* good – in full knowledge that people will judge the sites you have built on look and feel over functionality – despite the fact that you are not applying for a designer’s job at all.  But quite often the projects that look the prettiest are the most mundane and simple in terms of technology behind the scenes.  In addition to this, it’s rare (but not impossible) that you find an interviewer who is genuinely interested or excited by the way that you have achieved things technically, so talking through how you fully integrated your web application with Microsoft Sharepoint won’t interest them.  After all, all those months of development and there’s nothing fancy to see, only an “Update Website from Sharepoint” button in the web app’s control panel.  Really, it took 3 months to add that button?  I have a cousin in London who can do that kind of thing in an hour or two.