A conflict of objectives

February 15th, 2009

During particularly tight projects, particularly those for valued clients or high profile websites, there is often a tension between the project manager and the developer. This is my experience, anyway. The reason for this is pretty straight forward, and understanding this is key to a productive relationship. The project managers objective is to make the client happy. For them, this means keeping the developer focussed and on track to complete the work within the time allocated. For the developer the objective is less clear. On the one hand they must keep their project manager happy, by producing work the client will like, even be excited about. On the other hand, they have a responsibility to produce good, clean, manageable code.

The favoured approach is far too often the quick and dirty solution that gets the work done and paid for with a healthy margin. This is great until the project is revisited, and invariably it will. As average solution on top of average solution builds up, there comes a point when something breaks and there is no easy fix. Often, there is nothing the developer would rather do than scrap a bunch of code and rebuild it from the ground up. This is invariably time consuming, and frightening for the poor sod who’s job it is to test it all. There is also the consideration of who swallows the cost of this, as the client / project manager won’t see the immediate benefit of this kind of work, making it hard to justify.

The dangerous middle ground is the point at which trivial tasks become time consuming with unexpected repercussions and legacy code wrecks havoc with a beautiful solution. This guarantees stress for all involved and can strike fear into the heart of anyone threatened with involvement in the project.

So, what’s the solution? I had the first half of this post all planned out in my head, but now I’m kinda winging it. One solution is progressive deprecation. The strategy here is when tasked with implementing a new feature for project, to decide not only what needs to be built to fulfil the requirements, but what existing parts can be made redundant in the process. The process of evolution within a project critically must involve replacing old code with new, rather than just adding to what exists.

There is understandably a fear shared between the PM and the developer for work that stretches the scope of a job. At the end of the day, it boils down to the developer’s responsibility to look after his work. The projects I feel really good about are the ones where I’ve left the code in a better state than when I started. Often it’s tricky to convey this achievement to a PM, who is generally only interested in things that they can show off to the client.

This is where peer review among developers really comes into it’s own. I know from personal experience I write better code and make better technical decisions when part of a team. This is natural, it taps into the desire to show off and prove your worth to colleagues and when harnessed correctly can be powerful.

Thanks for reading, would be interested to hear your thoughts..

keeping it simple

February 9th, 2009

I’ve decided to experiment with a dead simple greyscale 3-column theme. I’ve decided I’m not ready for colour, and it’s pretty dull weather outside anyway. For now I’m focusing on getting the CSS and layout right. I’m planning on developing this into a very customisable, yet straight forward Wordpress theme to give away. Hope you like.

Of Patterns, Probabilities and Palindromes

January 26th, 2009

We discovered an interesting little problem last week. Interesting, that is, if you enjoy Maths a little more than is healthy. I was interested because what seemed to be a random problem when it should have been consistent, turned out just to be a random problem.

So here is what was happening. Our Sitewatcher was randomly showing a few sites returning 404 (page not found) errors. This was curious, because it was requesting the home page, and this page was certainly not missing. As it happens, there is a tiny weeny glitch with a couple of sites in that they will return a 404 code on the home page if the number 404 features in the query-string. This doesn’t happen in normal circumstances, but as cache:false was being used with jQuery, it was appending a random number to the request.

So here is the question. What is the probability of the number 404 occurring in a random 10 digit sequence? Not so trivial. Particularly because the number is itself is a palindrome. It can overlap itself, causing the number to appear as often as 4 times, making the calculation a little tricky.

We reckoned, by rough estimations, for it to be 1 in ~125, but no doubt a serious mathematician can enlighten us.

AIR time

January 5th, 2009

Christmas eve. Work was off to a slow start, hindered first by the office Wii, then by table football, and it was only 9.30am. While the rest of the company was at home winding down and preparing for Christmas, Craig & I decided to spend our last few hours on a side project, an Adobe AIR app. We’re the life and soul of Headscape, there’s no doubt.

Although I’d delved into the world of AIR before, I hadn’t really had a proper reason to create something. Our idea was simple, a site watcher. All it had to do was fire off requests to various sites and check the response code. Easy. We could build this with HTML and Javascript no problem. Throw in JQuery and you’re laughing.

The great thing about writing for AIr is that you’re coding for one rendering engine, and it’s webkit. This means writing webkit specific CSS rules completely guilt free. Rounded corners and RGBA can make your design pretty without many images. JQuery’s AJAX library is fantastic, it takes the pain out of requests and helps the code stay clean and readable. Within an hour we had a simple app running.

So we kept going. Using a plugin for JQuery the list became sortable, and the list of sites to watch was imported from an XML file. We created a private twitter account to keep a history of changes, and allow notifications via any standard twitter client. We also added a notification window so the app could be run in the background.

The experience was quite enjoyable, and relatively pain free. The only minor annoyances are having to develop CSS / JS without Firebug, but we managed. Aptana studio made for a competent IDE, and it’s code assistance is handy. Would definitely recommend giving it a whirl if you’re at all interested.

The AIR app is now available to download form Boagworld.comDownload site watcher AIR application

5 short iPhone stories

November 27th, 2008

Not original, but here are 5 short stories revolving around my iPhone. This isn’t meant as an iPhone glorifying article, but a collection of examples illustrating the cleverness of such devices.

I was up in London catching up with friends and enjoying the Great British Beer Festival, which was good fun. Happened upon Facebook, and started chatting to a friend I’d met over the summer, while climbing Kilimanjaro. Ended up going for sushi together the next day, had a marvellous time. Funny how things turn out.

I was at a friends house party, things were still warming up, and the guy with the tunes hadn’t turned up. Instead of faffing with laptops and playlists, we just fired up the Last.fm app, picked an artist and started a radio station. Not high quality, but plenty good enough and dead easy.

As server admin at Headscape, it’s sometimes my unfortunate responsibility to tend to a poorly server out of hours, particularly if it’s a production box. Often, a system restart is all that’s required, but this means firing up a remote desktop connection. Handily, I can VPN to work and remote onto a box, even over 3G. VPN on the iPhone is surprisingly easy.

Recently while in Brighton, we decided on going to the cinema. Flixter movies does an excellent job at finding cinema times of nearby cinemas (and providing trailers – could you ask for more?). Then by hitting the map location, find route -> by bus, we had all the info at our finger tips. Google took care of making sure we got to the cinema in time, and clued us all up on the busses home again.

While at Future of Web Apps earlier this year, I joined the rest of the email-addicted crowd, inseparable from work. Handy for my boss. However, the power was in using pdaNet / Netshare to have access on my MacBook in the evenings. One must question the wisdom of replying to urgent requests at 1am after rinsing a free bar, but it all worked out.

I’m not obscessed with my iPhone, I don’t need it or cry when the battery dies. Its just a nice little gadget. I do however compulsively check the app store for the latest new toy, and am regularly impressed with what I find. It seems it’s still new enough for developers to be excited / inspired / payed generously to build for.