Entries for archive: 2008-02

Found 5 entries.

Upgraded Kiwiwriters

After a few months of intense development and procrastination (yes, you can have both) I've finally upgraded KiwiWriters.

It's been a long haul. The last time KiwiWriters was updated was way before a number of changes that have been made to Zaapt. I won't go through all the details, but here's a rundown of the technologies that have changed under the hood.

changed OS from Debian Sarge to Etch
upgraded from Apache 1.3 to Apache 2
Postgres 7.4 to 8.1
an earlier Zaapt version to Zaapt 0.1 rc1

I know there are a few things I've missed but I plan on fixing those up over the weekend. It was about time I just did it rather than wait around anymore. Also, it's not a mission critical site (and it's volunteer work) so it gets as much time as it gets because no-one's paying for it :-)

Anyway, I'm glad to have finally done it because this means KiwiWriters is now using Zaapt v0.1 and now I can start of development for v0.2.

Excellent news :-)

Labels: zaapt, kiwiwriters, planet-geek, planet-catalyst

Inserted: 2008-02-28 23:57 (2 years, 5 months ago)

Your Environment

You are a product of your enviroment therefore your productivity is also affected by your environment.

Following on from yesterday's post regarding productivity, I'd like to now address the issue of how you can overcome these interruptions and hence increase your productivity (note that this article is aimed at people who work in a traditional office).

It was fairly obvious from the previous post that by removing as many distractions as you can from your developers you can get more out of them. But surely it's impossible to deal with them all isn't it? That's right, you can't. You have to deal with each one separately. The good thing is though like most sums, if you add one to the running total you come out at the same answer as you would if you took all of them together. In fact, you probably come out one better.

There are various forms of interruptions but I'm going to categorise them into four types: personal, technical, client and electronic.

Personal Interruptions

I consider these interruptions to be normal phone calls or when co-workers wander up to your desk in search of help. There is not much you can do to stop this form of communication but in reality most of these interruptions are fairly brief. They can usually be kept to one sitting such that when the questioner walks away from your desk, they have a fully formed answer which will keep them going for a long time.

Therefore, out of the 4 types of interruptions, these are the least invasive. You can stop them a little bit but generally these should be fine (for example, a previous team-leader of mine used to put on large construction worker's earmuffs to denote that she was not to be interrupted). So if you manage to conduct most of your interruptions either by phone or in person, then you'll be well on your way to being a highly productive developer.

Technical Interruptions

What I mean by these are the messages that are generated automatically by the systems you're managing. The messages themselves may arrive by SMS, IM, email or a myriad of other communication mediums. These types of interruptions are necessary but minimising how many you get is very important. There is no point interrupting someone for something that they can completely ignore. If the recipient can ignore a message then it means that the message itself contained zero information.

The best way to deal with these interruptions however is to have one person nominated on active duty. It is they who has to deal with any and all of these messages. During the course of processing one, they may have to call in the help from another member of the team but mostly the team's documented procedures should be able to get them out of trouble.

Unfortunately though these automatic messages are usually sent to a predetermined mailing list with numerous recipients but things like email filters can help in this respect.

So the best way to deal with these types of messages is to not receive them at all (unless you're the one dealing with them).

Client Interruptions

Client interuptions are a necessary evil. You can't create, sell and profit from something if you don't have clients. Lots of these interruptions are caused by email but there is a simple solution. Phone them up. If you're lucky enough to have your client in the same building as you, go and see them for a quick chat.

Clients also have a secret weapon up their sleeves though - they can create numerous different types of interruptions. Many times they want you to investigate something quirky, quote for something new, report on some data or do many other types of unusual request. There's nothing bad about any of this this but again, speaking to someone either on the phone or in person saves lots of time in the long run. If you need a written record of what was said, put it in your wiki or onto the relevant item in your issues list.

Sometimes the request virally spreads through to the rest of the development team such that more than one person is dealing with the whims of whatever the client sees as important today. This can (and should) be attacked at the front line. Each team should have just one interface person who is the first port of call for the client. This way the rest of the team is shielded from these interruptions and can get on with their own tasks (in that highly productive fashion we all aim for).

Every now and again, it might be a busy day to field all of the clients wishes such that one person can't handle everything. In this case the interface person will have to call in one of the busy developers for help. This isn't a problem since it is only a very occasional event. This is also true if the interface person can't actually fulfil the request. The bonus here though is that the interruption to the develper will be positively blazing since the interface person has already accrued as much information from the client as they need.

So all in all, these interruptions are necessary but there are ways of minimising this type from the team as a whole. The interface person deals with the main bulk of it and this job is rotated as necessary. That also means no-one gets tired of being constantly interrupted and not getting anything else done.

Electronic Interruptions

This category is the most invasive of all the interruptions and consists of email and instant messaging. The reason these things are so invasive is because of the long tail they create as soon as that initial message is sent.

These days, both of these forms of communication have become excuses for not having to actually speak to people. Instead of picking up the phone or wandering over to someone's desk, people just flick off an email or message and seem to hope the problem is now on someone else's desk. This is pure laziness and in reality causes more work than is necessary. The recipient firstly has to read the original email, interpret it, understand it (sometimes an impossible task) and finally respond to the message - in most cases by writing an email in reply. This email then goes through that exact same process at the other end.

If the sender had decided to pick up the phone (let's assume they're not in the current vicinity otherwise it just makes this situation even worse) the whole conversation could have been over within minutes. As it is, email is assumed to be instant and the sender expects a reply instantly too. As you can probably guess though, there is nothing instant about email at all. Not only does the email conversation then become a time hoarder, it also means that the developer is interrupted on numerous occasions during the ensuing tennis match (think of those long threads that just never seem to end). This doesn't even take into account that email can be misinterpreted and can easily turn into a pulling-your-hair-out moment. Think about it, how often have you been as annoyed at someone on the phone as you have been at their emails. I'd hazard a guess at almost none.

In the past, the advice given was to just check your email a few times a day however that just doesn't work. The problem is that we live in an instant society and therefore people expect answers within 10 minutes tops. How many times has someone come up to your desk and said "Did you read my email?" The email they talk about was sent less than a few minutes ago. Surely it would have been easier to just walk up in the first place. It certainly makes for a faster conversational turnaround.

Instant messaging is similar in the amount of time it takes to process. Even worse, there are ever smaller amounts of information in an instant message than there is with email. This also hoards time waiting for each response, let alone the fact that the original question didn't contain enough information for people to actually answer it correctly. Most of the time an answer is given and the original questioner then posts further information about why that answer given isn't even relevant! Or they suddenly found the answer by searching the internet (which they could have done in the first place and actually saved time for themselves let alone that of other people).

IM can also cause even more time wastage too. Many times I have seen the original questioner just keep asking further and further questions, simple questions with simple answers. Yet almost 40 minutes down the line the original question still hasn't been answered and mostly a quick chat with one or two people could have sorted the whole thing out in minutes.

But wait, there is one final sting in the tail for instant messaging and this one is a poisonous one. Not only has the original questioner distracted (usually) more than one person for 40 minutes, they have also distracted the numerous other people who also read that same channel. Currently in work, we may have something over 50 people on our internal IRC server. That's a lot of time spent reading useless questions which could have been answered in seconds in person.

There is a simple solution to both email and instant messaging distractions. Figure out who the best person to ask is and either go over to their desk or phone them up. If they're not the best person to ask they'd probably be able to point you to someone more capable.

But what happens if you're the recipient - easy peasy, phone the questioner up or simply go over to their desk.

Conclusion

Unfortunately, this post has become a lot longer than I originally anticipated. It has touched on a number of things but hopefully in some detail. Ultimately, removing most interruptions is best, dealing with certain interactions in a particular way helps stop others being distracted and finally, converting the invasive interruptions into less invasive ones helps enormously.

All in all, minimising interruptions means more development time, more time to be in the zone and much more productivity from your developers. Probably of an order of magnitude.

Labels: programming, planet-geek, planet-catalyst, productivity

Inserted: 2008-02-26 23:37 (2 years, 5 months ago)

Context Switching and Developer Productivity

We all know that when a developer gets interrupted from whatever he's doing, it wipes out a large amount of time, concentration levels and ultimately productivity.

Even ignoring what some really clever people say, sometimes you just know you're not as productive as you should be. Why? Because by the end of the day you think you yourself "Wow, I did nothing today". That's not always true, you've definitely done something but it just feels like you've done nothing.

So why is that whole lotta nothing feeling cropping up? Well let's look at three typical days at the office.

Every day starts out the same. You wake up, you go to work and just before you go through the main doors you think to yourself "Today, I'm going to finish that task off that has been bugging me for a while". It's the same every morning and the only variable is that task - it changes every so often.

Then you get three typical types of day.

The Highly Productive Day

A highly productive day is when you just hit the right notes the whole day. By hometime your forearms ache a little because you've been furiously writing tests, completing code, checking stuff in and deploying to the staging environment. You've been in your own little world, your concentration levels were amazing and everything just worked. Awesome. Time for a beer.

The Highly Frustrating Day

A highly frustrating day is when you've been busy all day, you've managed to get a lot done but there were a few things which just didn't work out. For whatever reason, that library you wanted to use didn't work as you thought, that weird bug in the browser killed too much time for your liking and finally you realised that what you had been developing was slightly wrong and you had to go back and change a few things. Days like this happen all the time, it's not your fault, you know it could have turned out differently but you have also learned a few things and tomorrow is going to be great. A little frustrating but you move on. Time for a beer.

The Highly Interruptive Day

Then there is the highly interruptive day. That task you have been working on didn't get more than 12.5 minutes attention per sitting. Something went wrong with the system which you had to fix up. The phone rang on numerous occasions. You had to quote for new work. People kept on coming up to ask for help. Finally to top it all off, that 12.5 minutes you did get to spend on your task didn't really work because your brain was so frazzled you literally figured out where your cursor was in the editor and then wondered what the hell you were editing in the first place anyway. You decide to go home instead of staying late because you just feel tired. Now it's definitely time for a beer.

So the main question about each of these three days is, which can you improve on? Obviously the Highly Productive Day was a good one. There's always room for improvement but hell, you felt awesome today. Things just worked out and you had loads of time to spend on that task. Also, during the Highly Frustrating Day you had lots of time to spend on the task but in all honesty these things just happen and you move on. Most days are somewhere between these two extremes.

Which leaves us with the Highly Interruptive Day. You fixed a couple of things, checked in some code but in all honesty you realise that that task you've had at the top of your list for weeks is still in exactly the same position it was in this morning. Granted, you moved a few lines of code around, you added a test and you even fixed some stuff but mostly you're exactly where you were before. The interuptions just kept on coming. Before you had finished dealing with one of them, the next interuption would turn up. Context switching when interupted takes lots of time anyway but context switching between interuptions - well, that makes for one unhappy programmer. Nothing seems to get done.

And after all that, you have no idea whether today should have been a Highly Productive or a Highly Frustrating day. You've done so little work you couldn't even gauge how it went. You can justify things by saying "Well, I'm basically a consultant now anyways" but really, you're expected to be a programmer, producing excellent code in what little time you actually have to develop.

So there lies the problem with the Highly Interruptive Days. In both of the previous cases you managed to do things, learn from things and improve things. But in this final case, you managed nothing.

Something funny then happens. As you're going home, you start switching off from work and start thinking about that other project you've got on the go. That one you have at home where you've been playing with new technologies, creating free software or just learning for the sake of it. Just to prove something to yourself, you realise that in the two hours you've spent hacking away with just an ambient bit of music in the background, you've produced more high quality code that you will in the rest of the week. No-one phoned up, no-one sent you email, or IM messages or came knocking on the door. You spent a solid two hours developing code, you were in the zone and it's actually still before midnight.

It's almost depressing to know that it still can be done if it wasn't for all those other inputs switching you out of context and just plainly getting in the way. And the worst thing is, you know tomorrow is going to be exactly the same.

Labels: programming, planet-geek, planet-catalyst, productivity

Inserted: 2008-02-26 00:53 (2 years, 5 months ago)

Amazon Web Services with Mike Culver

Tonight, we got a good opportunity to hear and see what Mike Culver (Web Services Evangelist) had to say about Amazon Web Services.

It was a good talk. A bit fast to go through everything but that's a reflection of how much Amazon have to offer. Lucky for me, I knew most of it but I did learn a few things along the way. Especially from the demo of using EC2. I wish he could have spoken more about SimpleDB though.

As it turns out, my plan to ask if I can be added to the Beta program for SimpleDB worked and I have just sent an email off asking if I can join it. So yeah, that makes me very happy.

The good thing is, as you know, I've been playing with S3 and s3bak a lot recently, but I've also been making a program to play with EC2 as well. It's actually not that big but already there is some good functionality. My plan to make a small command line interface to both SimpleDB and SQS is also in the pipeline.

It certainly is exciting to be playing with these technologies and while there are some criticisms against them, I'd say to see them as they are and watch them advance over time. The whole point of the whole setup is to be easy to use and it's up to us application developers to use them in new and enlightened ways, adding value along the way.

However, I do see a different problem though - oh so many ideas and oh so little time.

2008-02-20 10:31 - Update: I've just been added to SimpleDB Beta. Wow, they work fast :-)

2008-02-20 19:32 - Update: Don Christie (president of NZOSS) has linked to this article from his Pass the Source blog - When Amazon Comes to Town. Out of the 4 quotes of feedback, mine was the top one and one which I will try and expand into a bigger article later.

Labels: ec2, simpledb, aws, mike-culver, sqs, planet-geek, planet-catalyst, s3, s3bak, amazon

Inserted: 2008-02-19 22:07 (2 years, 5 months ago)

Other things I've been up to

I haven't posted in a while, but thought I'd let you know a couple of other things I've been up to.

It seems to have been pretty busy lately with 'just life', heading places, seeing people, enjoying the sun, but I really should get back to doing a bit more development stuff.

As a bit of an experiment, I have also been playing around with Flickr a lot more (please M$, don't buy Yahoo!, even if they are only good for Flickr). I have even set up a couple of groups too.

The first one is something that Donovan and I have been chatting about recently and that's having examples of NZ Native Trees so people can learn a bit more about them (okay, so I can learn a bit more). There is also a blog for NZ Native Trees which will showcase good example photos now and in future it will show tree, trunk, leaf, flower and seed examples of each native. It's a bit task (there are so few on Flickr) that we're going to have to take a lot of photos ourselves. If you can help, please add your photos, with tags, to the group.

Photo 'horoeka aka lancewood' by Brenda Anderson

The second group I started is one called Amazing Structures. I've always been fascinated with what humans can engineer on such a large scale. Already there are lots of photos (and I've already learnt my lesson to put a limit on what people can post) so hopefully that will kinda snowball. Again, I have a blog showcasing some of the best photos.

My favourite so far is this one:

Photo 'HSB Turning Torso' by olafuringi20