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.