Archive for April, 2007

Don’t blame others if they misunderstand you

Thursday, April 19th, 2007

Inspired by this blog post I thought I’d post my reply here.

Basically to summarise, if someone misunderstands your instructions then don’t blame them because you probably could have reworded your instructions to be more clear.

When I used to run an accounting software software business, if my helpdesk staff complained that the customer didn’t understand them and did something wrong etc, I’d say “you need to improve how you communicate to them then so there can be no misinterpretation”. For example, if you say “Shut down the PC”, a large % of shop workers will just press the off button, they won’t use the Windows Start menu to shut it down properly. Also if you say “close the server” meaning the “server program”, they will just power off or shut down the server PC. So the correct wording was very important to get the correct action, save time, and avoid frustration.

By the way, I had done every job in the company at some point so was experienced in the various pitfalls – thus I knew that my advice worked. I wanted my staff to feel comfortable listening to my advice because they knew that I had actually been there and done that. Formulating a theory of what might work is all very well but there is no substitute for direct experience. As my Aikido sensei says:

“A picture paints a thousand words, but an *experience* is worth a thousand pictures”

Do you set Milestones?

Thursday, April 19th, 2007

I’m contractually obliged to complete my current project by June 1st. So how can I make sure that I do that? By setting Milestones of course. If I was to just work on my project and hope that it will be ready in time one of three things could happen:

1) I actually finish it early because I’m an incredibly hard worker and/or the deadline was “easy”
2) Miraculously I finish bang on time with no loose ends.
3) I overrun by anywhere from a small to very large amount.

I have found option 3 to be the most common in development with myself in the past and with other developers that I’ve hired or been in contact with.

Who set the deadline?

One important thing to realise with deadlines is who set it. If it’s some date that a manager pulled out of a hat for you, you could be in trouble…If it’s a date that you set yourself then how did you arrive at that date? Did you just say “Yeah June sounds good, I’ll do it by then” or did you make a comprehensive plan overviewing all areas of the project and then assign time estimates (this takes experience by the way) to each part and then add on some contingency time before arriving at a viable date? Hopefully it was the second one. If you have been handed a date on plate by a third party (could even be a client) then make a plan, assign estimates and work out if you can complete the project on time. If not, then speak to them and ask what they want to remove from the project or if they want to change the date – it’s no use asking for an “extension”, school-project-style, the day before the project is due to be delivered (or worse still, not even contacting them and just being late).


OK so you’ve got a plan and a viable date, now how do you make sure that you finish on time? Sure, you could just work on the project a set amount of hours each day, dealing with problems as they arise and adding little extras here and there and then … oops you’ve missed the deadline. Why? Because all the unforseen problems and additional extras gradually padded the project out by weeks until you missed the deadline by a mile.

This is where Milestones come in. You look at your plan and use your time estimates to work out what you should have completed by Friday at the end of the first week. Then you repeat for all the other weeks in the project timescale. Then you start programming and if you haven’t hit your milestone by the Friday then you work all weekend until you have hit your milestone. It’s no use thinking that you’ll catch up later when some piece of work takes less time that you thought because it *never* happens (OK I’ll concede that if you are lucky, it *sometimes* happens).

Avoiding padding

So OK, how can you avoid working at the weekend every week as that’s not particularly desirable? Well you need to put the most effort in at the start of the week so that you finish on time or even early! If you finish early, then what? Well you could get a head start on the next piece of work or you could go back over the last week’s work and add some more polish – after all, if you are making a game, polish sells! Here’s a key point, if you get a bright idea halfway through the week don’t start to implement it immediately or you’ll fall behind. Make a note of all such “polish” ideas and see if there is time to put them in at the *end* of the week. Or, at the end of the project, if you have any time left (haha), you may be able to put some more polish items in then or you may be able to talk to the manager/customer and see if they even want the polish items – because sometimes they won’t as they just want the project delivered on time.


So to summarise:

1) Before making a commitment to a date, make an overview plan detailing each section of the project and attach time estimates to it. Then you know if the date is viable.
2) Set milestones based on your plan and time estimates.
3) Work hard at the start of the week (or better still, *all* week long) and make sure that you meet your milestone.
4) If you finish early, add some extra polish or get a head start on next week’s work.
5) If you miss the milestone, catch up right now, you cannot afford to let the lateness compound.
6) Note down polish items, ideas etc throughout the project and see if there is time to do them at the end or talk to the manager/customer and see if they even want them!

I hope that this article helps you with future projects. If you follow the techniques above (or a suitable variation of them), you’ll be amazed at how productive you can be in terms of delivering finished projects on time. If anyone disagrees with any points or has any other useful feedback or systems of your own, then please let me know! 🙂

Do your projects push your knowledge?

Thursday, April 19th, 2007

The developers among you may laugh but I figured out how to draw a Bezier curve yesterday and I’m feeling pleased with myself. They look nice don’t they?

I’ve also had to “relearn” 2D transformation matrices and projectile maths for my current project. Luckily I understood both (eventually!) enough to get them to work. These were things that I learnt at school but never really needed since then. Years ago I had to look up quadratic equations to solve a problem of how to make an alien’s bullet intercept your ship if your ship was moving.

It feels nice learning these things and making use of them in a game. Once in code form I can reuse them again easily too of course, and I don’t need to go through all the working out again – just copy and paste and change the parameters!

What have you had to learn recently that you’ve been pleased with?