I would like to propose a new law. If you are shopping in a supermarket you are allowed, with no consequence or dilema, to ignore people you know and get on with your business. No chit chat, no small talk, no conversation whatsoever.

I’m not being grumpy, well I am a bit, but my brain isn’t in conversation mode when I’m in Budgens, I am there for one reason and one reason only. I am buying stuff, and not particularly interesting stuff. Bog roll, Fairy liquid, mince, etc. I’m looking at a list, I’m trying to remember what goes in a mousaka, my brain is not in the right gear to switch into chatting.

Even worse if you bump into people just as you both arrive, after a quick disultory chat you then spend the next half hour bumping into each other as you go up and down the aisles doing the slightly embarressed nod and smile.

So – from now on – if I bump into you in Tescos I’ll say ‘Hi,’ and crack on. I’m not being rude, I’m not ignoring you I’m just trying to get my shopping done. If we see each other down the pub then of course I’ll talk to you and be friendly. Unless I’m trying to order a drink. Then you’ve got a better chance having a chat with Elivs.

I think that the time has come for me to compile my list of development nos. I’ve contracted for a while now and I see these things again and again. It could be read as a moan, but I hope not – these are my genuine thoughts on what not to do (unless you want to seriously jeopodise your application development). As with all lists like this it needs to be taken with a pinch of salt and also you need to recognise that there are situations where is is impossible to aviod doing them.

1 – Unrealistic time frames / deadlines

This is an easy excuse for a developer to use. Especially when the business owner has said it needs to be done in X amount of weeks without checking with the dev team if it is realistic, feasible or even possible.

Mind you – devs can be just as bad. I have myself gaily said “Should take a few days, a week max!” and then had to work late and still not make the deadline because I hadn’t thought the problem or application through properly.

SOLUTION

If you are a business owner talk to your dev team. Get them to think about it and give you timeframes.

If you are a dev DON’T give ballpark estimates. Think about it, look at the potential pitfalls, problems and also factor in some fuck up time. However don’t over estimate wildly or the business owner will start to get frustrated and will bipass you.

2 – Don’t work late

Beyond the obvious that people start to expect it, this is tied directly to point one. If you are consistantly working late, or even worse pulling all nighters, then it is an indicator that you have unrealistic time frames. At many agencies where I’ve contracted it is de regur to work till 8-9 in the evening (mind you sometimes people don’t get in till 10-11) or go all night in the run up to go live.

This is crazy. tired devs / designers / copywriters / project managers make cock ups and forget things. Whenever I’ve found myself in these situations at 9 at night I’m certainly not doing my best work. At worst I’m introducing new bugs into my code as I make mistakes. At 2 in the morning your “quick fix” could the next morning take 2 hours to rectify, and all of a sudden you are back where you were in the first place, just more tired. Things get forgotten, people get grumpy (in my case, really grumpy) and it turns into a “Lets just get this fucking thing done!” exercise, not “Let’s do it right so we don’t have to do it all over again.”

SOLUTION

First things first – see point one and don’t get into this situation if at all possible. However. We all know that there are situations where you need to do these sorts of hours. But plan for them. In the run up to a go live I tell my wife that for at least the last couple of days before I’m going to work late. She knows, I know and all is good. (Plus if it goes smoothly I can pop to the pub on the way home! Only joking Darling….. )

It’s when you don’t that you need to stay late and your loved one has organised a surprise special meal that you have problems. (For some reason – even though it’s a surprise it’s still your fault it screwed up!)

3 – No spec

“It’s really simple, it just does x,y and z.”

or

“It’s just like the other one you built, it just needs to do x extra.”

These, people, are NOT specs. It may be ball achingly clear to you what the application needs to do, but what I think is clear may be a million miles away from what you think is clear.

SOLUTION

Don’t risk it even for the simplest of build. Even half a page of bullet points is better than a quick chat.

4 – Boatloads of requirements

This sort of flies in the face of point three, but sometimes in order to make sure that the spec covers everything it covers EVERYTHING. Every conceivable, probably, possible or unlikely thing the app should, could or may do is piled into the spec.

To even start to try and build something based on a spec like this can be really intimidating and can be counter productive. You’ll spend the majority of your time building this massive app engine to cover everything on the spec and find that most of it isn’t used.

From extreme programing - 90% of this additional functionality will NEVER be used. So don’t bother building it.

(I shudder when people start talking about building generic applications to cover all sorts of situations)

SOLUTION

Pare the spec right back to the bare minimum to fulfil the brief and then iterate. Go for many little releases that one massive one.

5 – Forgetting that it needs to be tested (and that fixing bugs takes time)

So it’s all working on the laptop and (if you’ve got one) you’ve run through it on the dev server. All good to go then!

Well if you’re lucky all will be fine, but the law of Murphy will raise it’s ugly head.

Basically if you don’t test you are a muppet. And even though the dev that built it can do some of the testing the best is for someone else to do the testing. This tester should run some scenarios, hammer it (click on everything that can be clicked on – a lot) and try out unusual user journeys. If the dev does it they are so used to the system that they won’t do anything wierd, get lost, click on something stupid, refresh in the middle of a call to the server etc. And trust me doing stuff like the above will generate bugs.

Now for the important bit.

BUG FIXING TAKES TIME.

Sometime ages.

There is a perception that once we are in testing we are basically done. It’s a rubber stamp thing. There is also a perception – especially from the non coding side of the business – that once it goes into testing it should be finished, and if a bug shows up then the coders quite clearly don’t know what they are doing. I’m sorry but I’m sure that even Stephen Fry’s first draft of the QI script with have the odd spelling error or gramatical mistake.

SOLUTION

Appreciate that testing and fixing the bugs that come up are a part of the process, as important as building the app. Make sure there is a reasonable amount of time for this and push back at people trying to rush this vital part of the build through. A really good application can be ruined at this point where it is released early with bugs so it sinks without trace.

---

I hope this doesn’t come across as a moan and I also know that nothing I’m saying here is rocket science. What I do hope I’ve done is justify and explain why these are development no nos.

I’ve been a contactor for quite a few years now – with a break in the middle where I ran an agency with a friend for a couple of years (Nothing bad happened, we’re still friends and the agency is going great guns, it just wasn’t right for me at the time).  So I’ve got a lot of experience working in quite a number of companies and teams but I’m still not convinced I’ve got contracting, or at least my attitude towards it quite right.

Basically I am still a bit confused about what the role of a contractor is, and I also think that some of the clients I’ve worked for are also not clear.

Code Monkeys – Is this what we are?  Just guys brought in to fill a few holes and plug the resourcing gaps. Sometimes I suppose this is exactly what we are. The core team of developers have chosen the way they are going to build the application, the code framework we are going to use and have already picked up the cool bits of code to do.  As a contractor you step in to do the boring bit (because they are dull) or difficult, high risk or application vital bits (because no one wants to be left holding the baby when everything turns into a shit storm). I can understand this way of doing things, but it is expensive.  You don’t need an extra Flex developer sitting on your team on the off chance that a requirement comes in which needs another pair of hands, so when it does you get in a contractor. I’m also not really bothered about doing the bits no one else wants to either – it goes with the territory – if I wanted to try and make myself into a rock star (and I don’t honestly think I’m good enough to be one) I’d find the coolest agency in London and do everything to get a job.

If you are using contractors in this way then really you need to have an experienced in house architect, or at least an extremely experienced lead developer. Otherwise you end up with a team of contractors sitting around waiting to find out what they are supposed to do, or worse getting the wrong end of the stick and getting stuck in with gusto only to find out that they’ve done it all wrong.

The reason that you can do this with contractors is that we are pretty experienced ourselves, we’ve generally been coding to a high standard for a while and can hit the ground running regardless of the code or problem we are given. If you want it written in a certain way then as contractors we can do it that way. But should we?

Maybe as contractors our role should be more pro-active. Rather than sitting down and getting on with the job we are given we should take more of an active role in actually telling the rest of the team what we think and the way that we would do the job. Granted you can’t really do this when you are well into the project, or towards the end (which can be when agencies realise that they need another pair of hands) but when you are near the beginning of the project surely this is a good idea? As contractors we have worked in loads of different places, used tons of different development methodologies and seen many near misses and cock-ups and will have an opinion on how to avoid these problems in the future.

I tend to go down the middle of these routes. Make my opinion known and then get my head down and do what I’m asked too, but sometimes I wonder if being a slightly more opinionated developer at the outset would make the project, and my time at the client’s office, go a bit smoother.

This really is just me musing aloud (or blogging aloud – whatever…..;) ) I’m interested in what other contractors and also agency full timers think.