Note to managers: web developers are lying to you

Years ago, for reasons that now seem obscure and foreign, I was a school caretaker. When not spending idle hours chatting up the more amenable sixth form girls taking GCSE social studies (where are they now??)  we were basically lying about what we were doing. Because I’d seen a computer before – hell, I’d actually owned a Dragon 64 – I was designated “computer technician.” I took to the task with no small amount of fear. What if someone asked me about what I was doing?

I soon found out that they did ask me such questions. I also found out that they weren’t equipped to understand my answers (“I’m defragging some hard drives”, “I’m rebooting the system”). So although my answers were meaningless and even showcased the fact that I knew fuck all about computers, they went away happily. Presumably they reported this further up the chain when the headmaster banged on the desk and demanded to know what his computer technician was doing. “He’s scrolling through the contents of the C drive because that’s the only bit of MSDOS he knows how to use, Sir”. Anyway, I was never sacked but I did glean a bit of insight that I still see today: developers of any stripe will always lie about their progress.

The reason for this is very simple: most programmers are managed by non-programmers who aren’t even vaguely equipped to understand what’s happening below the surface.  This is perhaps most palpable in web design, where projects are typically overseen by a glorified sales guy. He will trot up to a desk and ask his developer: “How’s work on gormlessthing.com going?” The developer will show him the screens and click around, nonchantly choosing the bits of the website that are working – and then conversationally add little caveats like ‘”this bit’s a bit more complicated than I thought” or “I’m waiting for the client to get back to me on what goes in here.”

The clever developer will organise any project like this:

1. Get the visual side of things as near as damnit finished in the first few days. Increasingly, this is taken care of by the designer anyway so it’s an easy win.
2. Create database connections and the simplest bits of functionality so that the site can be said to be ‘working’
3. Drop dummy text in wherever possible and copy from page to page
4. Get on Gizmodo to drool over the latest iPhone/Jessica Alba nipple slip.

Web development is almost comically easier than desktop development in most cases. It’s a series of database queries in response to URL requests or form submissions, and a cunning developer can build 80-90% of any standard website in a few days.

The truly cunning will then spend a few days updating their Facebook status in such a way as to appear like they are working on the job (“Dave is stressed about gormlessthing.com”, “Sarah is instantiating classes!”) before uploading the site to some preview area or other, accompanied by an email about how they need the client to send over content for several pages and some product descriptions.

All of which buys them important breathing space for drinking cups of tea and trying to figure out a way to chat up girls on the internet.

Managers have got various schemes to try and overcome this gaps between what they can see (a website with ‘text to go here’ written in it), what they promised the client (the rootingest, shootingest website north, south west aaaaannddd east of La Pacos) and what the developers have actually achieved (“you’ve got a nice rack” is a failure as a chat up line). Most settle on the idea of the hourly rate or the ‘man day’.

Bigfoot, ESP, Spontaneous Human Combustion and The Hourly Rate: Myths to a man

At the start of a project, an estimate is drawn up that says: “this project will take 15 days to complete” – or 220 hours if management is that pernickety. Developers then get to cross that time off on a timesheet until all the budget has gone. By some miracle, all jobs come on either on budget or slightly over.

The first thing the developer figures out is that there is no reward for bringing a job in under budget. If they do that, all that happens is another job lands on their desk and they’ve got to start the whole tedious business of writing a website again. They certainly don’t get a cut of the profit –  it just goes to pay for the fucking sales guys’ expense accounts as far as they can see.

The second thing the realise is that these estimates are bizarrely off track. One sales guy pitches a job at £5000. Another one pitches something with more or less the same spec at £12000.  Either way, the work’s the same so the developer will stretch his timescale appropriately.

Thirdly, the developer can work at massively different speeds according to what else they’re doing. If they’re going on holiday at the end of the week they can churn out a website in two days flat. If a client keeps fucking phoning to point out a spelling mistake on the ‘about us’ page then progress can slow to a crawl.

All ways up, the developer will crank out perhaps 80% of a website in the first few days, then cruise for a bit until the pressure hits, and then run around in a blur over the last few days trying to bring the job in ‘on budget’ whilst introducing loads of cludges and workarounds to get the job finished on time.

How do you manage all this? I’ve no fucking idea – go hire a project manager for the answer! What am I? Burt Reynolds?