So I got into work today and was presented with the dreaded “You password will expire in 10 days. Do you want to change it now?”. So I said yes to get on with it, but surely this is a ridiculous security measure. How does this make my login more secure if you get me to change it all the time. I’m not going to take the time and effort to come up with a secure password and commit it to memory if every 6 weeks I’ve got to come up with a new one. All joking aside one of the team came back after Christmas and because they’d changed their password literally the day they left for holidays they couldn’t remember it. After nearly a day we got an administrator over from IT who reset the password for them. Nearly an entire contractor’s day wasted.

I’ve got a number of passwords stored in my head. I’ve got really really secure passwords with numbers, underscores and punctuation that I use for logging into my bank for example. They don’t ask me to change it every 6 weeks and if they did do you know what I’d probably do? I’d write it down. I need to get into my bank accounts and if I forgot the password and had to wait for them to reset the password, or got through the pain of a call to telephone banking it could be a serious problem (especially if I wanted to pay myself out of my business account). This is why banks DON’T make  you change your password all the time.

So dear IT bods at Auntie. Please stop making me change my password. I can’t be bothered coming up with a decent one anymore. D’ya know what I’ve done now? I’ve stuck with one password and each time you tell me to change it I add 1,2,3…etc. Probably not what you had in mind.

So I’m probably over a week late on this, but I wanted to hold fire until I’d had a chance to think  about the Flash and Apple row.

So the iPad doesn’t have Flash and the iPhone doesn’t have flash. Apparantly Steve Jobs has criticised Adobe for frankly being a bit shit about developing the Flash Player for the Mac and anyway HTML 5 is coming around the corner so that’ll sort out flash for once and all. And then the flame war began across the internet being mainly won by the flash haters going on about how it’s about time that Flash died – how inaccessible it is, how much you hate full flash sites, how it’s not standards compliant, how it’ll mean that all the advertising gets taken out. Well done Apple for eliminating this crap software from their version of the web.

I’m a Flash and Flex developer so I’m a bit biased, but bullshit. It’s not just Flash that doesn’t work. No plugins work on the iPhone and we have to presume on the iPad. Because people don’t tend to develop in Java Applets for the browser anymore we haven’t heard all of them complaining so the focus has been on the bad boy in the room – Flash.

The more important question to answer is “Why doesn’t the iPhone have a Flash Player?” – after all it’s a pretty open secret that Adobe have had the flash player working on an iPhone in their labs, and well too. So the performance argument is out of the way. Accessibilty? For the least accessible gadget ever created? Do me a favour. Might it be apps?

Long before Steve Jobs coined the phrase “apps” for the iPhone I like most other Flash and Flex developers have been creating apps. Apps for linking to backend data, charting, video players, audio players, games, chat, mash ups – hang on this is sounding a bit like wot the iPhone apps are all about.

So if Apple allow the Flash Player on their iPhone or iPad they may as well throw away their app store. Thats the real reason, the rest is just bull.

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 generally work in largish teams of people when I’m out on contract and I’ve noticied that even if you are sitting opposite someone you tend to use IM to communicate.  This could be Windows Messenger, Skype or one of the many many other IM clients.

Yesterday I found myself doing it again and I suddenly thought about how wierd this is.  You could reach over and physically touch someone and yet you are writing messages rather than talking.  Sometimes if it is important you’ll suddenly break out of the text chat and straight into a real voice conversation.  If you are overhearing this sort of communication it’s the most bizare thing.  All of a sudden someone deep in thought typing and staring at their screen will turn to the person next to them and say angrily “Yes – but I’ve appended the variables to the query string!” and the person they apparantly just started shouting at out of the blue calmly replies to them and then both parties go back to the squabble over IM.

Some people could argue that this method of communication is going to ruin social interaction (they’ll also probably read the Daily Mail) but I think that this can be a very important and valid ways to get things done.  But as with everything there is also a downside.

IM Pros

1 – How many times have I been deep in code, trying to think my way through or around a complicated problem and the someone has tapped me on the shoulder for a chat.  It completely breaks my flow and now I’m not really concentrating on either the conversation my colleague wants to have as I’m still half thinking about the code – but even worse I know it’s going to take at least 15 mins to get back into it.  If that person had quickly fired over a message on IM without breaking step I could zap back something along the lines of “Not now, give me x mins and we can talk.”  That way I’m not interupted and can get my job done faster and the person who wanted a chat will get my undivided attention when I’ve finished whatever I’m up to.

2 – You can have discussions over IM that you wouldn’t have out loud.  These could be along the lines of technical conversations where you need web addresses or lines of code zapped backwards and forwards.  You could be trying something out but you don’t want to broadcast to everyone in the immediate area that you don’t know if it’s going to work and you just want to work directly with someone else.

3 – You can speak your mind.  If you are worried about offending someone it is easier to have a text conversation as you can consider what it is you want to say before saying it.  This isn’t always possible in a face to face chat as you may forget an important point.  In a text chat you can take a bit of time to think rather than having to go straight back.

4 – You can ignore them.  You can’t ignore someone standing at your desk – it would be rude, but no one is going to get upset if you ignore a IM for a few minutes.

IM Cons

1 – It can be very secretive.  It is very easy to have a conversation behind someone’s back in plain sight.  Normally this may be the odd bitchy comment or exasperated “You’ll never guess what suchandsuch has done now!” that you’d probably have with people on your lunch break, but it can become quite insidious and undermining.  For example I was working with a weak Project Manager who was perfectly nice, but not really that effective.  This combined with everyone jumping on IM as soon as they’d just had a meeting with them to moan to the rest of the team pretty much wiped out any respect the team had for the PM and made a difficult project neigh on impossible.

2 – Its FUN!  Swapping jokes, firing over funny links or merely whittering to each other over IM is fantastic fun.  And possibly a major time waster.  This is probably the biggest worry for employers over using IM.  They want everyone to focus on their jobs and not thinking up witty retorts to their mate in Accounts.  However if your team does have loads of time to waste sending silly IMs or even worse are happy to ignore their work whilst sending messages then the problem is going to be something other then their IM habbit.

3 – Text communication removes all other human communication channels.  You cannot see someone’s face or read their body language.  It is really easy to write something (normally in jest) that is taken in the best case out of context or the worst case is taken really badly.  A quick example was someone asked me to change something over IM.  I sent back “Whatever” and didn’t add a smily at the end.  The next thing I knew the phone went and I had a really angry PM to deal with.  Even after I calmed them down I still am not convinced that I was just mucking around and of course I was happy to make the change.

So to sum up, and don’t forget this is only my opinion, I couldn’t work as effectivly without IM.  Even with the aparant stupidity of sending the guy sitting next to me IMs – I think as a method of unobtrusive communication about stuff that can wait it is vital.  Missusing IM I believe shows that there is a problem with something in the company, if someone is being undermined in IM chats then more than likely they would be undermined by people anyway.  If people are just using it to gossip then there is a problem with the respect of employees for the company.

Hello to the five or so people who accidentally find my blog.

If you’ve been here before you may notice that I’ve switched the design back to the standard theme and also changed the name of the blog.  Basically I’ve realised that although I am a web developer I can’t always post about developer stuff.  Writing tutorials for example, if you want to attempt to do them well anyway, takes bloody ages and I don’t have time to do that regularly.  Also although I may find a cool bit of code or nice way of doing something 9 times out of 10 I think about popping it up here and then realise that it’s probably going to be of interest to a very small number of people who have probably either discovered it themselves or come up with their own fix.

While I love my job as a developer I also started this blog because I’m interested in writing.  I used to write plays, sketches and I’ve got a couple of unfinished film scripts and novels knocking around that will probably never see the light of day.  But to be honest if they turn into anything that would be a bonus as the real purpose of them is for my own personal enjoyment of writing.

So I’ve decided that while I’m still going to have techy stuff on here, which would be impossible to avoid with the job I do, I’m not going to limit myself to just writing about code.

I’m also going to *gasp* do a bit of work on the site by actually doing a design and implementing it to fit in with my new content.

Right now I should probably apologise to the many readers of this blog which would be disappointed by this approach, but I see the stats – adding blowing tumbleweed would be an improvement.

Hopefully this new approach will get me writing more, and hopefully there’s someone out there who may be interested in what’s here, but realistically guys – I’m doing it for myself.   Sorry.

Here’s an interesting widget from www.nseries.com/vine.

Right – I’m pretty grumpy! Very grumpy in fact.  I’ve been working on a project and needed to use tweening.  So I thought no bother, quick job I’ll just use the standard Adobe AS3 tween classes.  Nice.  However all of a sudden I noticed that some of them started to hang.  Not all the time, I couldn’t replicate it consistently and also as the app relied on using the animations finishing to trigger the next event it was breaking the app.

If you’re having this problem check out this blog post and there is a fix in the comments.

That’ll do for now…..