Please help me with a research question

Hi All,

This isn't specifically a Java question, but is relevant to Java developers. I'm completing my PhD in CIS and researching the question of collaboration among developers. I could use your help to see if some of my conclusions are generally true in your environment.

1) Although you can generally say that there are more meetings during design of software, the concept of a programmer spending many hours and days alone only 'coding' is false. There are very few days where a developer communication isn't integral to getting the job done.

2) If I were to rank amount of collaboration it would be integration testing > design > coding.

3) There is a flurry of communication before and after status meetings, then people tend to work individually for a while. Status meetings tend to stimulate necessary developer communication.

4) Newbie developers are the biggest interruption to development "flow". (Even more than managers).

I'm assuming the environment is somewhat "traditional" - cubicles, weekly status meetings - rather than Agile, although my observation about meetings and phases would, I think, also follow.

If you have a minute to consider these questions, it would help.

Thanks,
Tom

1 couldn't be more true, as far as I can tell, we don't have any "code-crunchers" at where I work. Most developers spend hours working with the test team/each other to come up with a viable solution, then spend not very long implementing the code.

I'm not a developer atm (i'm a tester), but i would say about #2 is this: it SHOULD be design > testing > coding (observations from work), but in practice comes out coding > testing > design (especially when you're trying to meet weird deadlines).

3. I guess this doesn't really apply to me too much, I haven't been in too many meetings. However, we do talk quite a bit at work.

4... depends on who your managers are, and who you're newbies are. We have really great managers where I work, and I remember being new and kind of being in the way sometimes, but I have heard horror stories from people who use to work there before I did that the managers before weren't worth anything. Plus, new eyes mean you catch issues (especially in regression testing) that have either been ignored in the past, or simply missed because the test procedures are sometimes "mundane". I don't know if this only applies to the testers side, but I'd imagine something similar happening with new developers (new ideas/ways to implement stuff)

FYI, I guess I don't work in a very "traditional" cubicle setting. Yes, I do have a cubicle, but the vast majority of my time is spent working in our labs.

edit:

Oh, haha didn't see the part about "Java developers". While I do use Java at work, it's not something that's used by most of our company. I think we use a combination of c++/custom scripting languages/not sure what else.

Ok, lets see, right now I'm working on the first timebox of a project at work. We just got through a 7 workday foundation package to outline the requirements and tasks of this project work package.

This timebox is about 2 weeks long and the work package is about 6 weeks long. The whole work package will most likely have 3 timeboxes.

I have the need to collaborate with my fellow developers, both server and web all the time as well as with the business ambassador and the project visionaries to get things done.

Every day we have a daily standup meeting to talk about how everyone is doing and as soon as a task has been completed/unit tested, it goes over to testing while we proceed with more tasks. Each task is about 0.25 to 2 days long.

This project is being run using the agile method rather than the old fashioned waterfall method and I like it :)

I wouldn't see myself as a newbie developer but I'm new to this project and I didn't have much clue on how things tied together before I joined, however I tend to pick things up fairly quick.

Something that can be really annoying with general work is when you can't get a hold of a business representative to answer a question or to make a decision when you've hit a brick wall with a task.

// Json

Quote:

---

Originally Posted by Json

Every day we have a daily standup meeting to talk about how everyone is doing and as soon as a task has been completed/unit tested, it goes over to testing while we proceed with more tasks. Each task is about 0.25 to 2 days long.

---

I've noticed, particularly after standup meetings, that pairs of developers often go off together to coordinate on integration tasks. This is also true after (non-agile) status meetings. Is this true in general for Agile? [Json, is this true in your environment?]

Also, "going over to testing" means that the tester inevitably has questions -- or finds bugs -- so a developer needs periodic communications with QA. Again this interrupts programmer "flow" since they then need to talk about 'old' software, or devote time away from developing new software to fix bugs.

I didn't define programmer 'flow', but I think you understand. It is that state where a developer is totally immersed in his work, doesn't hear outside distractions, and interruptions are considered to be distractions.

One question about your Agile environment Json. Is it an "open area"? Are there benefits/distractions associated with this?

Thanks,
Tom

At this moment we are 4 server developers, 2 web developers, 1 tester, 1 analyst, 1 business ambassador and we're all sat in the same room and thats all there is in there at the moment.

I wouldnt say that we go off in pairs to discuss things after a standup but instead if someone comes across an issue that needs discussing we'll just discuss it. We're never THAT much into the flow so to speak that we cant stop and discuss things however most of the time we just carry on with our own work.

The tester tests tasks as we finish them and we have daily demos of tasks so the tester knows how to use what we've just built. All this has been estimated for as well so the project isn't delayed or anything.

Hope that answers your questions.

// Json