Starting on the wrong foot

I've just joined a new project as a team member - my role is to write software. I'm keen to start off with domain driven design, really connecting with the users that know the processes and understand why things happen. At the moment we're writing some code to test some of our ideas to make sure we've got the skills we think we do.

I do think that domain driven design will be tough, especially getting buy in from managers to take the time of their domain experts to work through how they work and how they think, but that's all yet to come - our business analyst has done some great work on gathering initial requirements, so I think people are ready for the discussion that will come soon.

One of the big surprises for me is the lack of 'project team' or culture that has been created. Now, I work as a 'resource' (how good does that make you feel?) underneath my manager who has been more involved in the planning phase, but now that I'm actually part of the team, surely there should be some feeling of being part of a team? Bas de Baar of Project Shrink has quite a lot of articles about the culture in projects - well worth your time to have a look at. So I'm wondering what to do about this. It's got me quite frustrated over the last few weeks, especially as having tough conversations is made harder if you don't have a basis to work from.

My current plan is to organise a lunch outing, it'll at least be a start. I'd also be keen to go lawn bowling, but I'm not sure if anyone else would be keen, so it might not be so much of a winner for team culture.

Language difficulties

I went to the optometrist a few days ago. The optometrist that did my examination was really thorough and helpful, but there were a few things in the way she spoke that got my attention.

I'll talk about the points, and about how it can relate to working as a software developer.

Timing: when I'm supposed to choose from 2 lenses, seeing 3 lenses doesn't help. There were occasions when I didn't know which lense was 'one' or 'two'. Agreeing on which one I thought was better was also tough because I would say 'one' when specifying the better lense, and she would say 'one' - I wasn't sure if that was a question or statement, so wasn't sure if she'd noted my choice and had moved to the next test, or if she was checking what my decision was.

Suggestive language: The choice between two lenses shouldn't be influenced by anything other than what I'm seeing - several times the optometrist said 'one is better isn't it', putting into my mind that I shouldn't be choosing two.

Rewarding subjective choices: Similar to suggestive language, rewarding one choice or another makes you question if you made the 'right' choice.

Sitting in the chair being examined got me thinking about how I talk to people when I'm gathering requirements, talking to people about the problems they're trying to solve and discussing problems with colleagues.

I think its easy to jump to a solution, or assume requirements before allowing the subject matter expert really explain the situation. Just using neutral language to ask questions rather than a suggestive question, allowing them time to give more information.

When providing feedback its important to be really clear that you're providing feedback. Using phrases such as 'I'm going to summarise what I think we've talked about, if I've left anything out or got something wrong please tell me'.

This is just another great reason for software to be released often, it lets the discrepancy between my understanding of the situation and the users be exposed. Even when we work hard at understanding each other, it hits the road when they actually have to use what you've made.

In any case, I got some new contacts, and they're all sweet!

Where does your seat sit?

1-12-10 Another Day in the Cube
Originally uploaded by Patric Woessner

At work today, we had a bit of a chat about our physical work environment. Currently we've got an open plan setup happening, everyone faces into their corner of the workspace, and we've got space for a whiteboard. One of the issues with the current setup is that pair programming and code reviewing is a bit hard - trying to fit 2 people into a corner doesn't really work very well, and we want to start doing more code reviews to up the quality of our work.

I know that some people are big advocates of the 'everyone get's an office' idea, and have been reading Joel Spolsky's blog - particularly about office space. I think it'd be great to have my own office, but we don't really have the space, so we're trying to think about how we can work better in the space that we've got.

One idea is to have a large table that we all work at in the middle of the area, with whiteboards around the outside so we can draw and discuss ideas. Another possibility is to all work around the edge of the area, facing the wall, but not have anyone sitting in the corners - which will help with pairing and collaboration. A space would be reserved for a whiteboard, and we could wheel in another whiteboard in and out when we needed.

Anyway, hopefully over the next couple of months we can figure out a way to work better together, which may include a redesign of our physical work environment.

How do you work best with your team? Do you sit near each other? How does working remotely affect your collaboration?

Pair programming

Originally uploaded by ThaRainbow.

A while ago my colleague and I started work on a new project so we decided to do some pair programming, which was the first time I had worked like this. My colleague, having worked with pairing before at a previous job, took the lead. We'd been talking about using agile methodologies for a while, and thought it was a good opportunity to have a go.

At first, it was pretty awkward, as neither of us were overly good at communicating our coding plans, so we'd often wait till the other nutted out a bit of an idea, and then talked it over. We tried writing tests first, which was pretty successful, but once again, trying to figure where the other was going was pretty hard work.

We only worked together for a few days, and then got split to work on separate projects, but I would love to try  it again.

A couple of things that I found:

• Pairing is humbling - if you don't know something, it becomes pretty obvious fast. 
• Ideas are up for grabs - no one is going to be right all the time - you've gotta be prepared to put your ideas out there, and be prepared to talk them over and admit that you aren't always right
• Great collaboration - although it's hard, it's a great way to learn and discuss ideas. It makes you work hard to communicate effectively - which is a great skill to generally have. 
• Promotes openness - I find the way I like to work is on my own, but being pushed to work with others and be transparent is quite liberating, and it means you aren't the one source of all information.

How do you go working with others? If it's software, have you tried paring? If you're not a developer, what are some ways that you've been forced to work with others that have been surprisingly beneficial? 

Google Wave

We just used Google Wave at work today, tried to get a bit of collaboration going. It was my first time giving it a go, and I think the concept is pretty good. We've got a SharePoint site up for our project, but that doesn't really allow for real-time conversations. We're trying to get a feel the gaps in our project, so we can follow them up later.

I like the idea of post it notes and a whiteboard, but Wave keeps all the conversations in one spot, although I'm not sure if technology actually takes away from the collaboration process at this point - especially when we're all in a room together.

How do you collaborate? Have you given Wave a go?