If you enjoy fixing bugs in other people’s code then unfortunately you’re not the right person for us…

If you’re keen to learn, prepared to work hard and won’t complain too loudly when asked to fix bugs in other people’s code when the need arises then please get your CV over.

See the full requirements over in the Jobs section.

For instance, I’ve got a friend who used to work as a DJ, and he is incapable of going into a club or bar without immediately checking out the equipment used there and seeing how it’s set up. Equally, it’s impossible for me not to get advice from anyone who’s ever worked behind a bar whenever I make a complete hash of trying to pour a drink into a glass without creating enough head to have my own foam party.

The environment that I’ve mainly worked in (digital agencies) means that it’s also against the law of nature for me to have a website open in front of me without some designer or even project manager make some comment about how good or hideous the design or layout is. At which I can only shrug my shoulders and say I don’t really care how it looks as I’m a back-end developer (insert your own joke here) and as long as it works I’m happy.

Now, when I come across sites that don’t work properly, a variety of thoughts go through my head, foremost among them is deciding how annoyed to be at the incompetence of the developers/testers of the site to bring a halt to my journey so abruptly. Two factors govern how many times I scream at the monitor that I could code better than that; one, deciding whether the site belongs to a small shop and probably maintained by novice self taught coders using a variety of help manuals or a large corporation with enough resources to keep a whole army of programmers on. If I decide on the former then most of the time I would chuckle to myself, make an ‘ah bless’ comment and then move on. However, if it’s the latter then I would tut loudly and start making a mental list of what coding error could have possibly caused the problem.

The length of this list would be determined by my second factor, whether the error is actually an error or whether the site just doesn’t do what you or a 1 year old would expect it to. If it’s an error, then I would move on fairly quickly, as even programmers are human and will make mistakes. However, if it’s more of a case of extreme bad planning and thought then I get really annoyed. The prime example of which is the Transport for London site (TFL), (for those of you aren’t in London and really couldn’t care less about what happens inside it, tough) earlier this summer a cycle hire scheme was launched and you can now buy access on their site in order to use it. All well and good, you pay either £1, £5 or £45 for a day, week or year’s access respectively, great. There is an option when you sign up to decide whether you want to automatically renew your access subscription as it expires, useful, but I decided not to at the time. However, being human and therefore also certainly likely to change my mind I later decided that I would like to enable this option. So I logged into my account, full of hope and confidence and found out that the system wouldn’t let me do this one simple thing! Investigating further, it appears that once my subscription is expired the system will no longer let me alter settings in my account, and that I would have to ring up TFL and get someone there to do it!

To me, this is just mind boggling, firstly, what sort of lazy programming (and testing) let this bug get released into the world? My head is full of images of lines of code gone wrong that would lead to this. Secondly, seeing as it’s possible for their customer service team to do this at their end, it would suggest that the core functionality of the site allows this function, and it’s just the customer facing website that is defective. In which case, it’s been over 6 months since the scheme was launched and this problem reported, so why is it not fixed!? We are talking about TFL, a large corporation with a pretty hefty budget at its disposal for this sort of thing and not a corner shop with a shoestring budget. Plus, in my head, unless it’s such a monumentally badly coded site, it really shouldn’t be that difficult to fix.

When IE6 was first released in late 2001 it was received with great enthusiasm and relief by a development community that was bloodied and battered by the browser wars between Netscape and Microsoft. It was the golden child; the browser that finally killed the beast that was Netscape 4.

That was then, this is now. When compared to modern browsers such as Firefox, Chrome, Safari and Opera, IE6 is old, buggy, insecure, and doesn’t fully support all the fancy stuff we do today with CSS and Javascript.

Why, when IE9 is just around the corner, do we need to continue to support it? Is it because clients are insisting that their sites need to work in IE6 in the same way they do in modern browsers? Is it because the target audience are likely to be using IE6? If that’s the case then we need to educate our clients and their target audience about the limitations of IE6. We need to get them to upgrade or switch to a more modern browser if they want to experience what the web is capable of today. They won’t get that with graceful degradation.

With the arrival of HTML5 and CSS3 it’s time to look forwards, not backwards. It’s time to say goodbye to IE6.

Client: So how’s the reverse ratchet flux capacitor engagement system actually going to work?
Me: Magic
Client: Great, let’s build it.

I could substitute the word Magic with a details of how the flux capacitor engagement system will use a quantum tri-state to maintain a parallax field while pushing phased particles through a cloud substrate but the client really doesn’t care.  That’s the wonderful thing about technology and perception of technology these days.  People’s expectations are higher, yes, but people generally have much more trust in technology’s ability to perform.

One of my first commercial web applications was on online jobs site for a national newspaper that allowed recruiters to upload job postings and users to search and view them.  Back in 2001 this required what seemed like endless meetings to discuss and document the technical platform.  Everything from network redundancy and fault tolerance to the architecture of the COM components that would be written was documented and had to be reviewed and signed-off by the client. We probably spent as much time writing technical documentation as we did writing code – and the client was happy to pay for it to get the reassurance they required and the belief that should something go wrong, they had their arse covered!

Fast forward to 2010 and although now longer involved with the same national newspaper, similar scale projects for similar clients no longer require anything like that level of technical documentation.  That’s not to say that similar planning exercises do not happen behind the scenes, they do, it’s just that clients tend not to want to spend their money on reams of documentation that will never get read, and, more importantly, have much more confidence in technology’s ability to deliver.  They no longer have the need to understand (or even try to understand) the ‘how’, and are happy to concentrate on the ‘why’ and the ‘when’.  Any reassurance or due-diligence required is (and should be) focused on usability and design rather than technical ability.

Very few people try and understand how iPlayer works, or how Facebook uses memcached to achieve such a high level of performance, they are happy to accept that they ‘just work’, or are, as I like to put it, ‘Magic’!

The process of gathering requirements and system design is always thought of as a pretty linear process.  The theory goes that as you gather more and more requirements you are better equipped to organise them and create the perfect system.  Basically the relationship between understanding and time is one-to-one.  A bit like the graph below.

Linear requirements process

If this was the case then it would make sense to spend the necessary time gaining a complete understanding of the system.  Not only is each quanta of time (let’s say a day) worth the same, if you spend enough of them you will eventually get to a state of perfect understanding which will allow you to go off and employ a team of developers to build the perfect system without any further thought.

Now everybody knows that this doesn’t actually work in practice and however much effort you spend designing a system there will always be things that for whatever reason don’t quite work in the real world.  Not everyone is quite so keen to admit that the theory is flawed so normally the blame is put on the implementation of the process:

“We really must make sure our design is more comprehensive next time.”

In reality the process of gathering requirements and system design is not linear.  There’s normally a pretty steep curve at the beginning of the process as you get an idea of the core requirements and this tends to level off the more time that is spent.  Arguably you never really get complete understanding and you can certainly never design the perfect system.

I think the curve looks a bit like this one:

Actual requirements process

So, there comes a point where it’s not really worth gathering any more requirements or spending any more effort designing the system as each day that is spent brings less and less extra knowledge.

Common sense tells you that you should stop trying to increase understanding at a point when the curve starts to level off and start building something.

When to start building

The trick is knowing how long it’s going to take to reach that point, recognising that you’ve got there and knowing what to do next…