Email As a Means of Social Communication

Recently I’ve been spending a lot of time away from home, and busy with clients within office hours, which means I’m not available via my usual real-time communication mechanisms. This has given me the opportunity to enjoy email as a means of staying in touch with people that I would more usually chat with on IRC or some form of instant messaging.

When I write an email, I’m usually (mostly) doing that one thing, and the result is quite joined-up. Anyone who has had the experience of trying to carry on a conversation with me over messaging when I’m doing multiple things knows that I can easily lose the thread of an explanation and I often find I have to read back the logs of a conversation to be able to keep up.

When someone takes the time to write an email, the reader can’t interrupt or divert the writer and so the writer is able to express their points at their own pace. Email is also easier to re-read and reformat, if you are the kind of writer that doesn’t necessarily think of everything that needs to be said in quite the order it ought to be said.

When someone is emailing asking me to do something, I won’t lose an email (you’d be surprised how often I lose things people ask me to do on IRC, its on a par with asking me in the pub). Admittedly, my inbox can be several months deep but when I have time to attend to your query, I will – and that goes for social correspondence as well.

Finally, and most importantly, it enables me to stay in touch with people whose committments don’t fit around mine in terms of online availability due to work, life, or timezones.

I’m quite enjoying a slightly more formal exchange of the written word with those friends who are emailing me while I’m on these little jaunts – you know who you are and I don’t enjoy being away from home so those little messages are welcome, thanks :) And for everyone else – next time you are lurking online looking out for someone, take the time to write an email instead – and let me know how it works for you.

Burndown Charts

Disclaimer: I am not an expert on this topic and have never studied it formally. This is purely an explanation of how I’ve seen these charts used within Ibuildings and included in my talk Passing the Joel Test in the PHP World which triggered lots of questions and tweeting.

Burndown charts are a way of tracking how much work was estimated to be remaining at a given point in time, and we track this over time to give us some idea of the rate of change. We start with some estimates, then we track how much time is left at regular intervals, I do this daily, because its a sensible unit but there are no rules. Its much easier to show this rather than tell it so here is an example – we’re making a dolls house.


(yes, this is a photo of me. This was my fourth birthday and the dolls house was a home-made gift from my parents – I still have it)

Task List and Estimates

We need some numbers to start with, and I don’t mean looking at a task and going “a week and a half … ish?”! Tasks need to be in small enough increments that we can safely estimate them. By “safely” I mean realistically and hopefully accurately enough that you won’t find your project manager following you to your car at night with a pitchfork in his hand. For our dolls house, the table looks something like this:

Task Estimate
Assemble pre-built frame 2
Paint exterior 2
Paint windowframes 1
Decorate rooms 27
Fit carpets 5
Add furniture 1

As you can see, we’ve got a large element listed in the middle of the table – 27 hours is too big to be a single estimate, so we’ll break it down further.

Task Estimate
Assemble pre-built frame 2
Paint exterior 2
Paint windowframes 1
Decorate bedrooms 8
Decorate kitchen 7
Decorate bathroom 5
Decorate reception rooms 7
Fit carpets 5
Add furniture 1

Charting Estimate Remaining Over Time

The aim of this is to chart how the estimated outstanding work changes over time. So we start with the total estimates in place – I’ve added a week’s worth of days, just because its easy to fit onto the page, but your chart might have dates rather than days and go on for longer. Each day copies the number of hours of the previous day as its initial value – we’ll edit them when they change.

On Monday, all the work is still to be done, so we start with a chart that looks like this:

Task Estimate Mon Tue Wed Thu Fri
Assemble pre-built frame 2 2 2 2 2 2
Paint exterior 2 2 2 2 2 2
Paint windowframes 1 1 1 1 1 1
Decorate bedrooms 8 8 8 8 8 8
Decorate kitchen 7 7 7 7 7 7
Decorate bathroom 5 5 5 5 5 5
Decorate reception rooms 7 7 7 7 7 7
Fit carpets 5 5 5 5 5 5
Add furniture 1 1 1 1 1 1

To make the chart is as simple as adding a “total” field to each of the day columns and turning that into a bar chart:

Let’s say on Monday we get the first two tasks done – we set the “Monday” column for these tasks to zero because there is nothing outstanding. Now our table and chart look like this:

Task Estimate Mon Tue Wed Thu Fri
Assemble pre-built frame 2 0 0 0 0 0
Paint exterior 2 0 0 0 0 0
Paint windowframes 1 1 1 1 1 1
Decorate bedrooms 8 8 8 8 8 8
Decorate kitchen 7 7 7 7 7 7
Decorate bathroom 5 5 5 5 5 5
Decorate reception rooms 7 7 7 7 7 7
Fit carpets 5 5 5 5 5 5
Add furniture 1 1 1 1 1 1

So each time some work is done which causes the estimated remaining work to be reduced, we update the figures in the table.

During the Main Phase

Imagine we’re partway through and its Thursday, let’s check in on our dolls house project:

Task Estimate Mon Tue Wed Thu Fri
Assemble pre-built frame 2 0 0 0 0 0
Paint exterior 2 0 0 0 0 0
Paint windowframes 1 1 1 1 1 1
Decorate bedrooms 8 8 8 6 1 1
Decorate kitchen 7 7 7 7 7 7
Decorate bathroom 5 5 5 5 2 2
Decorate reception rooms 7 7 3 3 3 3
Fit carpets 5 5 5 5 5 5
Add furniture 1 1 1 1 1 1

At this point, its pretty obvious that the project isn’t going well. The curve on the chart isn’t steep enough to be able to reach zero by Friday and without having to interrogate developers (who of course are always 90% finished), we can see that overall, things aren’t great. Project managers may know that there is one blocker which is causing the problem but if you didn’t know … then you do now :)

A closer look at the numbers against the tasks show that we started the reception rooms and the bathroom but neither are finished, the bedroom we’ve worked on for the last couple of days and its almost there … you get the picture.

The Aim of the Game

The ideal burndown chart tends towards zero at the point at which the project needs to be finished … but working this way gives a nice graphical overview of whether thing are heading in that direction or not. Flat lines are generally the sign of something bad, and progress is really visible even when its spread across many tasks or many developers. The chart could have a column for who owns each task, and for extra points add an “actual” column so you can compare how the team performs against its estimates (this is “project velocity”).

This post was really only intended to show things as I see and use them – if this helps you then great. If you want the “official” version then I can only suggest you get a book on scrum and find out how to do it from someone much more qualified than me :) If you’re using this or something similar, then I’d love to hear how it works out for you and what you do differently – leave comments and tell me!

Announcement: Editor-in-Chief of Ibuildings Techportal

A few weeks ago I got a call from my employers, Ibuildings, asking me how I felt about changing my role a bit and taking on some of the functions of our PCE (PHP Centre of Expertise). This area of the company does some super-cool stuff and so I said I’d be interested. Fast forward a bit and I’m on a call with Ivo Jansch (our CTO, who also oversees PCE) talking about what kind of things I could be involved in. I cannot describe the surprise I felt when he asked if I would take on the role of Editor-in-Chief at our developer portal site, techPortal … and of course I jumped at the chance.

I’ll be picking up a few other community-facing functions for Ibuildings but techPortal is the headline news, I’m super-excited to be entrusted with this project as our existing Editor-in-Chief, Cal Evans moves on from Ibuildings. Now the announcement has been made I guess its real … wish me luck :)

PHP Barcelona 2009: Round-Up

I spent the last few days in sunny Spain at the PHP Barcelona conference as a speaker. Happily the most reasonably-priced flights gave me some time while I was there to get into the city, I was very keen to see it because I haven’t been before. The trip was made much more enjoyable by our gracious hosts who transported us between the venue and hotel most nights (and it was a very nice hotel too!) and arranged a speaker dinner that I thoroughly enjoyed.

The conference itself was excellent – I spoke about “Working with Web Services” which is basically an overview of everything you need to know to be able to consume web services. The slides for that are online at http://www.slideshare.net/lornajane/working-with-web-services.

I also saw some great talks from the other speakers there, some were people I often see at conferences, others were familiar names, and yet more were people I’d never heard of but I certainly learned a lot from all these groups. One thing that struck me was that the majority of the conference talks were in English – my experiences from looking at these events in southern Europe is that they tend to be held in the local language which of course makes them much less useful to me. This event was predominantly in English, the introduction and (most of) closing session were in English, and most of the talks were too. Whether this signifies a shift in the culture of technical events in Spain or whether this was simply a nice decision by the organisers I’m not sure.

I also made it out into the city which was beautiful. When I publicised my trips, so many people sent me information about their favourite places to go, trips to take and so on that I dubbed Barcelona “city of memories”! I didn’t make it to very many of those this time around but I’ll definitely return to the city in the future – its simply breathtaking.

Parc Guell

Congratulations to the organisers – I’m looking forward to the event in 2010 ;)

Accessible UK Train Times

A very quick entry today to mention a site that I’ve been using a LOT lately and I know I will be relying on for large quantities of travelling right through November: Accessible UK Train Timetables. It has up-to-the-minute information, including platform numbers, and you can bookmark queries for the next train between two points along with some other very cool shortcuts.

A site like this, which presents information very cleanly and I can easily use off my phone, is an excellent example of a good use of published data and I’m very grateful to them for this resource which really helps me when I’m out and about!

Add a heartbeat method to your service

Over the summer months I wrote a series of posts about designing APIs in general, and web services in particular. This included posts on status codes for web services, error feedback for web services, auth mechanisms for web services, saving state in web services and using version parameters with web services. I thought my series was finished but I thought of something that should have been included – perhaps the series will keep growing as I learn more?

I’ve worked with a couple of services recently that have a rather excellent feature – a method which calls the service but doesn’t do anything useful but simply lets you know the service is alive and well and residing at the location you thought it was. These “heartbeat” methods just allow consumers to check for signs of life, verifying that the service exists.

The heartbeat shouldn’t require any particular parameters or any authentication, since formatting data and passing credentials can be a stumbling block for those integrating with a service for the first time or those debugging issues. The heartbeat method can return some known data, perhaps an “I’m here” message, and maybe some version information. Flickr has a nice method flickr.test.echo which will also echo back any parameters that were sent to it – which could be useful for debugging values which don’t arrive at the server as you expected.

Another use for a heartbeat method is to allow monitoring systems to call a simple method, needing no credentials, and always get the same response back. Its not uncommon for these monitoring systems to be pointed at a particular page, and for failures to be indicated if the contents of that page changes (because data in the system changes, for example).

So – build a heartbeat service, you might never use it but when you need it, you’ll be glad you did!

Stash-Busting Striped Ripple Crochet Baby Blanket

For a few month I’ve been working on a handmade blanket for a baby expected by a couple of my friends – and I’ve finally been to visit and deliver it so here’s some details of the project. (OK so baby Ethan is about a month old and I only just made it round but, meh, life’s been busy! On the plus side, he’s big enough to be alert and kick about on his mat and look at us so that was really cute!!)

Its a basic ripple pattern, I have the 7 Day Afghans book and I reduced one of the patterns in there to baby-size with fewer repeats. It was a 6ml hook and the wool was taken entirely from my existing stash, basically it was a stripe or two of each of the DK weight wool I had lying around. So it’s colourful, and it helped make space in my life for more wool, and it was very inexpensive (i.e. free!), so on the whole the perfect project. Here’s the finished article:

Ethan's Blanket

And a close-up of those ripples:

Ethan's Blanket closeup

I’ve made a round ripple before but never a straight one, although I kept looking at patterns for them. When I heard about Deb’s pregnancy, I knew this was exactly the blanket I wanted to make! So, welcome Ethan, and good health to all the family.

Speaking at Bradford LUG

Next week I’m taking the plunge and attending a LUG (Linux User Group) meeting for the first time when I attend the Bradford LUG meeting on Wednesday as a speaker. I’ll be giving my talk “Working With Web Services” which I’ll give at PHP Barcelona a mere 36 hours later (Wednesday is the dry-run, let’s hope it goes well!). I’m excited about this topic and looking forward to meeting a new group of geeks – if you are in the area then I hope you’ll pop in and join us.

Pigeon Print

Recently I was working (I work from home) and I heard a really loud impact noise, like a football being kicked really really hard against something. At the moment my desk is in the attic, I looked at the cat, but he was asleep in the same room as me and hadn’t even looked up at the noise. I set off down the house, wondering if I needed to shout at next door’s kids for kicking the ball against something … and then I saw this

Pidgeon imprint

I’m pretty sure that wasn’t there earlier – this is my landing window so you walk past it all the time. A pigeon (I’m guessing) must have flown right into the window. I got a fright – but I can’t imagine how the bird felt!

Book Review: PHP Team Development

I was recently contacted by Packt Publishing asking if I would review a copy of one of their new titles – PHP Team Development. I happily agreed and the book promptly arrived in the post (just in time for me to take it on holiday and read it by the pool!).

Overall I was quite disappointed by the book – although at least half of that was due to the poor written English contained there. Some sentences didn’t even make sense, I’m not accustomed to reading anything other than clear English (“Vendor Locking” confused me for a while), and the language in this publication made reading the whole thing rather slow going. That said, for a brand new team of PHP developers with no previous experience of working in a team, there were some useful points in this book. Its clear that the author’s experience lies in a large organisation building a single product, whereas I’d say the level of this book would apply well to web development shops with a handful of developers probably working on a series of different projects for clients.

There are some solid concepts introduced – few are explained in detail though and after a couple of chapters I think a less experienced developer would have had a list of terms to look up rather than new ideas to try! Still, there are good explanations of source control, MVC, templating, and OOP elsewhere on the web and in other books so it would be possible for someone to follow up on this. I was particularly alarmed at the concept where one team writes the model, another writes the view and yet another writes the controller to tie them all together. Perhaps in big enough development teams, with a lot of up-front specifications written, this can work. My on-the-ground experience though would lead me to group tasks together by feature rather than separate them by bits of implementation – I currently work in an organisation that uses agile projects though where features are the whole point of the exercise, so perhaps that influences me.

On the whole, a perfectly nice book for beginners (available from the publishers or from Amazon)
but if you are already working in a team then you probably won’t get a lot from this experience.