In agile development methodologies, pair programming is considered a key practice. Pair programming involves two programmers (in any combination of novice and/or expert) working together to write code. Advocates of agile methodologies outline a range of advantages of pair programming, and I’ve always thought that, in theory and as a relative outsider to the code writing process, it would be a great approach to development. I’ve never worked on a project where there was budget or resource available for pair programming though.
In the past 12 months or so, practitioners of the various design disciplines that I’m interested in have been talking more and more about agile methodologies and how they might apply to design processes. There’s been a lot of talk of collaborative design and rapid iteration, but I’ve not seen anyone talking much about ‘pair designing’.
In my experience, designing can often be a rather lonely activity. If you’re fortunate enough to be able to integrate real users into your design methodology then that can break it up a little. If you’re working within a team of other designers, perhaps you’ll be able to get them to review your work from time to time and give you some feedback. Working in a ‘pair design’ environment is, however, quite rare.
I’ve been fortunate enough to work on a few projects where we’ve taken a ‘pair design’ approach (in fact, I’m working on one right now), and I’ve been pleasantly surprised that the benefits that the agile advocates outline for pair programming largely hold true for pair design.
Increased discipline. Pairing partners are more likely to “do the right thing” and are less likely to take long breaks. Whilst I like to think that I ‘do the right thing’ when I’m designing solo, I have certainly found that working with another designer does heighten your focus on the task at hand and, even more importantly, lengthens the time that this level of focus can be maintained.I’ve also found that in pair design, you tend to design more away from the computer, instead using flip charts and pencil and paper, and post it notes stuck all over walls and drawings and user flows that you’ve mapped out on paper.This is good design practice but, even better, keeps you away from the distraction of email, and bloglines, and all the other kinds of distractions that you find on your computer. It keeps you focussed on the design process.This makes you design better, and makes you more efficient.
Better code. Pairing partners are less likely to go down ratholes and tend to come up with higher quality designs. I don’t know about ratholes… But I do know that when designing in pairs there tends to be a more rigorous approach taken to design decisions. This is because you have to be able to explain each decision you’re making, or design approach you’re taking AS you make it, not in retrospect. Each decision needs to be justifiable. And, because you have someone there designing with you, you get to actually discuss the benefits of each approach rather than just doing what you think is best (or worse… what you can do most easily in Visio because you have a template already set up that way…. Oh, come on. You know you’ve done it.)On the ‘going down ratholes’ issue though, if you happen to be designing with your client, then you are able to check really quickly whether the approach you’re taking has a hope in hell of being adopted by the client. This means that you don’t waste time designing something that will never be implemented, and that what you do design has a much better chance of adoption.On that note – designing with your client means that they understand the rationale behind every design decision. So, if you’re just a temporary resource on the project, you leave behind an evangelist for your design – again, making it more likely that what you’ve designed will actually survive the development phase.
Resilient flow. Pairing leads to a different kind of flow than programming alone, but it does lead to flow. Pairing flow happens more quickly: one programmer asks the other, “What were we working on?” Pairing flow is also more resilient to interruptions: one programmer deals with the interruption while the other keeps working. For me, getting stuck into designing IS flow. But see above re: increased discipline and below re: less interruption. Both of those definitely mean you get lots more flow time, which is all good.
Improved morale. Pair programming can be more enjoyable for some engineers than programming alone.As I mentioned before, designing solo can be a lonely business. When you crack a really curly design problem, there’s no one to celebrate with… well, no one who really gets it. With pair design, you have a celebration partner. This is good :)
Collective code ownership. When everyone on a project is pair programming, and pairs rotate frequently, everybody gains a working knowledge of the entire codebase.OK. This has been a little less relevant to me, as a consultant, but see above re: designing with your client and gaining and evangelist.
Mentoring. Everyone, even junior programmers, possess knowledge that others don’t. Pair programming is a painless way of spreading that knowledge. This is almost certainly true when you have an expert/novice pairing, but even when you have two designers with similar experience there is a lot to be learned.How often do you get to actually watch the process that other designers go through and how they approach their work? Not often, I’d guess. This is a great opportunity to say, ‘so hey, here’s how I do it… how would you do this?’ and pick up some handy new ideas or approaches or Visio tricks. (Hey, none of us know everything, do we!)
Team cohesion. People get to know each other more quickly when pair programming. Pair programming may encourage team gelling. Yep. Pair designing is definitely a great icebreaker :)
Fewer interruptions. People are more reluctant to interrupt a pair than they are to interrupt someone working alone.Now, this one is DEFINITELY true, and don’t underestimate how important this is. You can get an awful lot of design done in a couple of hours if that’s ALL that you’re doing. But how often do you actually get this much time to do nothing but the design you’re working on? In my case, not that often. Two people in a room makes you MUCH less interruptable!
One fewer workstation required. Since two people use one workstation, one fewer workstation is required, and therefore the extra workstation can be used for other purposes. Well, in our case we abandoned workstations all together and took over a small office/war room. So, I guess there have been a couple of free workstations!
Choosing the right co-designer is pretty important. I’d be loathe to pair design with someone who knew nothing about interaction design… it would be way too much mentoring and not enough designing, which isn’t practical or appropriate on a ‘project’ based design. i would however suggest that if you find a client who has people with the right skills, you do what you can to try to get them involved. This is much more likely if you’re applying other agile methods that involve rapid designing and iterating.Now, it would be unrealistic to suggest that pair design be adopted for all design projects, it’s never going to happen, and in many situations would be unnecessary.
But, if you do have the chance to work this kind of methodology into your project, then I’d encourage you to go for it. I think you’ll find it a very rewarding experience.
Have you experienced pair design? I’d be really interested to hear if you’ve had similarly good experiences, or if there are some horror stories out there!
Having been a project manager in a past life, and still working day to day on projects, I watch with interest the deployment of a range of web based project management tools. In a lot of ways it’s like a dream come true. For most of us, Microsoft Project – the only real project management tool available beforehand – is possibly the most over featured piece of software in the world.
I’ve heard it said that most people only use about 5% of Microsoft Word’s functionality… I can’t imagine what a miniscule proportion of functionality most people use in Microsoft Project. And like MS Word but worse, often times that unused functionality would rear up and cause problems for users who didn’t understand it or weren’t aware of it.
Not only that, but it’s also prohibitively expensive. So unless you’re working in a company where they’ve got the finance and inclination to pay for your license fee – you’re unlikely to get access to it.
Then along comes 37 Signals with Basecamp, BackPack and TaDa Lists . Project managers everywhere were ecstatic (not to mention all those David Allen Getting Things Done disciples). With the ability to create and assign tasks, to post messages, to do simple scheduling and starting at the bargain price of free – 37 Signals and their products soon had a lot of evangelists wondering aloud how they ever managed without these web based project management tools.
Just last night I got my invitation to check out GoPlan. It’s been developed by the team at WeBreakStuff, so I had pretty high expectations. These guys think a lot about usability and user experience, so their work should be top notch. And, I have to say, I wasn’t disappointed.
GoPlan is a spunky looking piece of web application, and it has lots of great functionality.
You can create multiple projects with multiple users (users with varied permission to access content and functionality), there’s notes, a project blog, a calendar, a file upload.
GoPlan also has two similar but different sections called Tasks and Tickets. Tasks, I assume, are things you have to do in the course of the project. You can assign it to a category but not a person, and you can assign a deadline to it (although, strangely that doesn’t make it show up in the calendar). Tickets, I assume, are for bugs and variations. You can assign a priority, a severity (is it just me, or are these two *very* similar criteria… when is a critical severity ever a low priority? I guess there are exceptions… nevermind, tangent).
Oh, and there’s a cool inbuilt ‘chat’ so you can have your rapid fire online discussions AND keep a record of what you actually decided!
All good. All a lot like the 37 Signals offering. But all slightly disappointing to someone who’s managed some reasonably complex projects in her time.
I never thought I’d say it, but I miss the Gantt Chart.
I think it’s quite interesting that both 37 Signals and WeBreakStuff have not used any visualisation tools as a part of their project management offerings. (Well, ok GoPlan has a calendar… do we count that? I might if their task deadlines integrated with the calendar, so for now.. no).
One of the most recognisable features of Microsoft Project is the Gantt chart it generates. Back when I used to make lots of big MS Project files, I thought that I was really just making those charts for my clients (they’re pretty, they look seriously impressive – wow! that’s one complicated project!… this was before Getting Real, ok!)
Interestingly, if you take a look at 37 Sig’s Manifesto for BaseCamp, this is one of the first things you’ll read:
Projects don’t fail from of a lack of charts, graphs, reports, or statistics, they fail from a lack of communication.
Ah yes. But what I’ve come to notice is that charts, graphs, reports and statistics do more than just impress clients. And they can play an important role in communication, and motivation.
A Gantt chart is a graphical representation of the duration of tasks against the progression of time.
You can see why that might come in handy.
At a simplistic level – nothing focusses attention like a Gantt Chart with lots of red on it – indicating that you’re way behind schedule.
On a more practical level – when constructing project plans, I’ve come to realise how much I did actually rely on the Gantt Chart to help eliminate errors in my scheduling, and to quickly see the implications of alternate scheduling, risks and delays.
When reviewing a complex project plan to see if I’d made errors in scheduling, or understanding project relationships, or if I’d just missed lots of stuff out – it was the Gantt Chart that would most quickly let me know if I’d stuffed up. Breaks in the flow, a critical path that just stops (before the end of the project), tasks that just look too long or too short compared to the tasks around them – all rapid visual indicators that something’s not right.
It get’s really hard and boring to read through a long list of tasks, and even more difficult to understand the relationships between tasks in this format. This is where the Gantt Chart comes into it’s own. Relationships between tasks and groups of tasks are immediately apparent. Tasks that are on the critical path are obvious.
In retrospect, I’d have to say that Gantt Charts were really important in eliminating errors in project planning for me, back in the day.
So, the Gantt Chart is much more than just client eye candy. It also plays a real role in faciliating the detailed planning phase of the project. It also helps with rapid comprehension of project progress and task relationships as the project continues.
Gantt Charts allow you to understand how long your project is going to take, in what order tasks need to be undertaken (no, it’s not always self evident!), and what tasks are dependent on other tasks. This means that if you move tasks around, or some tasks get delayed, you can see what’s going to happen to your project as a result.
This is all really handy stuff to know if you’re managing a team and have a deadline. It helps you communicate within the team, and to your client, early and accurately. It helps everyone make decisions.
In both the 37 Signals products as in GoPlan, there seems to be no notion of a critical path, or dependencies between tasks. To me, that means that I either have to work a lot harder to keep my projects under control or to impose a structure of my own, or that these products are only intended for reasonably simple projects where, perhaps, the deadline is not such a big deal.
I’ve been using BackPack and BaseCamp for almost as long as they’ve been available, and I have to say that they’ve certainly been valuable to me. Particularly when I was freelancing and had to manage my own tasks on several projects. In these cases though, when I was working on big projects, I was a resource (information architect) and someone else was a project manager who had the biggest Gantt Chart you’ve ever seen in your life! (I needed a separate tool just to manage my tasks!)
I find it intriguing that both 37 Sigs and GoPlan seem to have taken such an anti-chart approach to their tools (and there’s much more than just the Gantt chart that they could have included). I suspect it’s to do with the lack of the critical path. Or perhaps, they’re not actually *project* management tools, but ‘sets of tasks’ tools.
Either way – if any one’s planning a web based PM tool that *does* include a critical path and some pretty pictures… I’d really love to see it!
Moo Flickr Mini Cards launched recently, as you may have read elsewhere. I’m stoked to see so many people checking them out and enjoying them because I had the pleasure of working with the Moo Team on the design of the service.
Moo took a really inclusive and user centric approach to the development of this interface – doing user research and testing in a range of different environments throughout the design and development lifecycle. It’s really great to see that some of the things that we at Flow found when we were working with them are now part of the design – and it’s been great to see the design evolve over time as more and more people got involved in the Moo project.
So, designing, and developing and feedback were locked into a really fast and iterative process – and the end result is a process of selecting, designing and ordering cards that is – I think, and others seem to agree – really easy and enjoyable.
Based on what I know of their ethos and approach, I feel confident that Moo will continue to evolve and improve the interface and user experience of Moo Flickr Mini Cards over time.
It’s been really great working with the guys at Moo because of the responsiveness and user centric approach that they’ve taken to this project. I look forward to seeing how this product evolves and where else Moo shows up – they’re a really smart crew, doing really smart work! Yay Moo! :)
So, I went to the Girl Geeks Dinner in London last evening. It was an interesting night. The first thing you need to know if you’re thinking of going, is that it’s not a dinner. It’s drinks and a talk. But it’s still good.
I went there knowing absolutely no one, and ended up meeting a few people (hooray to those girls who were brave enough to introduce themselves to people they’ve never met… this happened about three times throughout the night, I did it a few times but not as bravely as some!)
One thing I’m taking away from the evening is that I need to find a way to talk about what I do that sounds as exciting as I think it is. As you do when you don’t know anyone, you find yourself explaining what you do with your time at work. You’d know by now that I’m pretty enthusiastic about my work – but I know that when I talk about it, it doesn’t have that zing. That’s something to work on.
Someone who does much better at it is Abigail Sellen. She’s been involved in amazing HCI work for ages. At the moment, she’s working with Microsoft. Abigail gave a really interesting talk to the Geeky Girls. I loved her relaxed presentation style. Abigail has been doing this work and talking about it a lot. She has such an understated approach, but her CV is so incredibly sexy, I suppose it’s easy to be understated.
Abigail says – if you’re going to *really* innovate – really do something out of the square – then be prepared for a ten year wait to see it go to market- otherwise be prepared to engage in taking it to market (getting out of the research lab and going out for lunch with product managers, engaging with the economics and the politics of the organisation outside of the research lab). She was talking about projects they were working on ten years ago that we’re looking at today and thinking ‘how sexy’. Seen that two handed desktop interaction? That kind of thing. They were working on it ten years ago and now the market is almost ready to find a place for it.
If you want to take innovation to market quickly, then focus on tweaks. Find ways to make existing technology work better. And this is no small task. Abigail gave the example of the mobile phone and the way that SMS completely revolutionised what that device meant to people and how they used it. That’s a reasonably small innovation that came to market reasonably quickly (depending on what market you’re in) and made huge changes.
At Microsoft they’ve been looking at the home technology market. Their thinking is that up until now, home technology has been divided into two areas: time saving and time wasting. This is a pretty simple breakdown, they say, and there must be some more interesting opportunities for technology in this environment – like for using it to allow people to express themselves, to emote, and for supporting families.
Really interesting stuff – enough to turn some of us green with jealousy, I’m sure. Sometimes I really like the idea of working in a research lab. But then, they too have frustrations – such as the ten year wait, and the products that are designed but never get to market, and getting IP Patents for all your ideas can’t be that much fun either.
It was definitely worth the effort to make it to Geek Girls and I’d recommend it to other London gals. Get along and check it out!
Meanwhile – check out Sarah Blow’s great t-shirt (picture above). It’s a customised XXL Mans Microsoft .NET tshirt. Microsoft has never looked so cool. Mash-up of the year I reckon :)