Apps

What size programming team do you prefer?

Do you work best on a small team or a large team, or do you prefer to be a "lone wolf" programmer? Take this poll to let us know.

Every developer feels they work best in a specific type of team. Some developers like larger teams, where each person has a strongly defined role and sticks with it, such as developers, senior developers, architects, and project managers. Other developers prefer smaller teams with a "many hats" type of role assignment. And yet other developers thrive in a "lone wolf" scenario where they are a one person team.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

About

Justin James is the Lead Architect for Conigent.

10 comments
jslarochelle
jslarochelle

I did that because I am tired of having 200% workload and unrealistic deadlines. We really are going for project that are too large for the team that we have. Even if the company was willing to hire additionnal people (which it is not...except for the Indian division) the problem would be to find enough really good programmers. I just hate badly written code. So it is a dilemma: I'm a loner so I like to work alone but I would like to have a life outside of work so I would like a larger team. JS

Justin James
Justin James

Do you like to be alone, or if you prefer a team, how big, and what mix of people? Do you consider PMs, BAs, QA, etc. part of the "development team"? J.Ja

Izzmo
Izzmo

I voted for small team exactly for the reason it stated: The agility. I like being able to delegate set tasks to your team and then be able to discuss with them about it as well as help eachother along the way. With large teams, this can be a daunting task since your members might be on the other end of the Earth.

Tony Hopkinson
Tony Hopkinson

No customers, for instance. You can 'work alone' in a team, it's not that you are the only one. Just a clear separation of tasks. No different to going at something big by yourself but in segments. First the database, the busines logic, then the UI, or whatever order you feel most comfortable with. The trick is to get the big picture fairly well sorted, then open up the black box lids and rummage around. Doesn't matter how many people you have if they aren't working on the 'same' thing.... This is the bit most PM's eschew in favour of three useful metrics and dashboard report of abysmal failure.

CG IT
CG IT

If the project is to create an application from scratch, then there are various skills needed at various times. This means that the team might be large during startup for dwindle down in the deployment and support phase.

Tony Hopkinson
Tony Hopkinson

at least two developers. Larger tasks should be broken in to pairs, overlapping ones if the architecture can encompass that. I've always believed in involvement. Putting hard lines between the various disciplines, BA, QA and dev, leads you to to the throw it over the partition type environment. Lots of rework and or disatisfied 'customers'. The overall product quality becomes entirely dependant on the communication, and that usually sucks....

jck
jck

I like a small team of capable people who understand what is involved, and a project manager who knows how to relay that information both to the development team, other management, and the customer. Depending on the project...1-8 people. Where I am now, my manager is a brilliant guy. However, he has a hard time communicating. Rather than explaining things, he often just sits down at your keyboard and starts coding things for you. I can learn just from watching, but others on staff don't do as well with it. So, as he writes code like a bullet train for them, he's really doing no good in explaining concepts and strategies in what he's done so they can benefit. Do I count these as part of the "development" team: PM (Project Manager, I assume): Yes. That's your coordinator and interface to the customer. BA (Business Analyst?): No, that's R&D QA (Quality Assurance?): No, that's functional and requirements testing/QC

jslarochelle
jslarochelle

I guess my statement was more an expression of my frustration. You are also right that getting everyone to work on the same thing is critical. Implicit in all that of course is that a bigger team does not necessarily mean things will improve. However, there is a critical mass that should match the scale of the project. JS

dave.schutz
dave.schutz

I never work alone, I always have the voices in my head.

Editor's Picks