• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Programmers, Do you think it's effective to work in a big group

joutlaw

joutlaw

Golden Member
Lately I've been hating my job. My title is a Senior Programmer Analyst, but I feel more like I'm back in QA where I started my career.

Project Management has been making us meet with other business users in a conference room and basically work there. I could be working at my desk, but feel I'm being micro-managed from a whole new level.

My boss is on this kick lately with a project that we have been working on for over a year. He has what he calls war room where 9 of us are in a meeting room. Basically it's just his code that is getting defects, but it seems he wants us all in there holding his hand. So it's him in his code and it seems he just wants us to look over his shoulder the whole time. He then puts a fix in and we run some test cases to see if he fixed it ... what I consider QA work. We have Team Foundation Server have unit tests that can fire off automatically when we run builds... so I think lets go with that and let QA do their job.

Lately I'm just having a horrible time working like this. Not only do people start to get on your nerves when you are around them that long... our boss doesn't look to kindly on breaks and never takes any himself. That coupled with the fact this project has been dragging for over a year is making me really want to look elsewhere, but I'm afraid to with the economy and housing market.

So back to the subject... I think this is a horrible way to work as a programmer. My boss thinks everyone should know everything about everyone's code in the group which I feel is impossible and not effective. I think you need specialization in a big project and put people where they work best. I also don't see how one person programming and 8 watching is productive, but he seems to think we are getting so much accomplished.

Sorry for my rant, but I'm just frustrated with my job and possibly career choice at the moment.
 
sounds like a shitty situation.

where are you located, fatwallet is looking for a couple new programmers right now.
 
I'm in Jackson, MS... not that many jobs here relative to the southeast.

I think a lot of the problem here in the project management office. They report direct to the CEO so they have a little superiority complex. Since their existance a few years ago I have seen no difference in the speed at which things get done. They may have simplified a few things, but the red tape and additional layer of communication has made things evolve slower in my opinion.
 
Software engineers are supposed to do unit tests because they are white box tests. If you are talking about final qualification testing that proves that your software meets requirements, that is black box testing that is to be done independently. This black box testing falls under QA I guess even though that is not what it is called where I work. QA is a group of people that is supposed to make sure you are doing things according to the book, whatever "the book" is where you work.

"My boss thinks everyone should know everything about everyone's code in the group which I feel is impossible and not effective"
This is true for one person, the software lead. Everyone else should atleast know what hte overall architecture and design is though.

Pair programming works well. Two developers, one computer. Your boss is doing the right thing, but totally incorrectly. If he want to PAIR program, he should but that only requiers 1 person.

I can see how your project could eventually become behind schedule.
 
Pair programming is ok, but mostly just a way to give management types the warm and fuzzies. The situation OP is in is just stupid.
 
pair programming is good in short increments. 30 minutes to 2 hours. enough to solve a specific problem or work through a challenging solution.
its great for when one of the programmers is super familiar with a specific appliction or section, and the other programmer is super familiar with another - and the project involves both sections or codebases.

the OPs manager needs someone to put him in his place.
 
IMO programmers are like threads, they work best when they work on different tasks that have little shared data. Tell your boss he is wasting resources by having a team of 9 programmers sit around looking over his shoulder to make sure he programs well. If he thinks a 15 min break is bad, how much worse is 9 people doing the work of 1 or 2 people at most? You are basically wasting 7 workers days every time you do this little stunt.

It sounds really unproductive to me and I would definitely bring it up to him.
 
I wouldn't be happy there either.

I think pair programming and code reviews(by peers, not managers) are great tools to bring the overall quality of code and knowledge up in a given group of programmers. Nobody is going to be at the same level of knowledge and spreading around the expertise will not only help people learn and improve their skills but it also results in cleaner/better code. Now, if all you do is pair programming(or group non-programming in the OP's case) then there are problems too. Everybody should be able to pull their own weight for their part of the project, but utilizing the knowledge of others on your team to help you code will only help the overall project.
 
9 people in one room? You can't get anything done like that. 4 at most and even then they shouldn't all be working on the same thing.

It sounds to me the project manager is concerned about his programming skills, but wants to make sure he can still program in case he loses his job as a manager. I would be pretty miserable myself in that situation.
 
Thanks for the replies. I was hoping it's not my personality that is causing the problem. I just think it's a huge waste of time... especially when he wants to us to stay late and I'm salaried.

We do pair programming and I like that when we're just in my cube. I can get a lot done that way.

I've been trying to think of the best to approach him about this. I'm afraid of coming off disrespecful, but there are other people in the group who are pretty miserable too. Although we do have a couple who go the brown nose route and stay attached to his hip at all times. Ironically they are most incompetent.

 
I know its nerve wracking, considering hard economic times, but your best bet is to talk with him 1 on 1 and tell the truth. Put your argument on paper with any evidence you can gather. Tell your peers who feel the same to do the same as you. Then, offer a solution to what he is trying to accomplish with the 9 man war room. If he isn't a complete dilbert stereotype, he should seriously consider your request.

You'd be surprised with how much management respects proactive (thus bolded solution part above) and thoughtful employees. If he is a total asswipe, then you are screwed either way.
 
Originally posted by: joutlaw
Thanks for the replies. I was hoping it's not my personality that is causing the problem. I just think it's a huge waste of time... especially when he wants to us to stay late and I'm salaried.

We do pair programming and I like that when we're just in my cube. I can get a lot done that way.

I've been trying to think of the best to approach him about this. I'm afraid of coming off disrespecful, but there are other people in the group who are pretty miserable too. Although we do have a couple who go the brown nose route and stay attached to his hip at all times. Ironically they are most incompetent.
Click to expand...

How else do you think incompetent people get ahead in life?

You going to sound disrespectful no matter how you bring it up to him (I believe). So I would just go with straight forward and blunt. "Boss dude, I don't really like these 5 hour war room sessions, I just feel like we could be more productive if we split up into smaller groups and worked separately. As it is, I feel like the 9 of us are doing the same job that 2 could do, it is wasting the time of 7 people."

Something like that. If him getting mad at you is worse then your productivity, then just smile and only tell him this if he asks for you opinion.
 
Im a scientific programmer, so this may not apply, but i would HATE that situation. Honestly, its a "too many cooks ruining the pot" situation. Tell your boss to fuck off, and stop showing up to these "meetings." Wait, thats what i would do, but i have a phd, probably a bit different from your situation.
 
I cannot think of any way this could be an effective way to program anything. Plan and design? Sure. But actual code writing? No way.
It's not any different than trying to have nine authors working on the same chapter of a book or nine mechanics trying to work on the same engine--and I can't see anyone thinking those would be good ideas either.
 
I find the only way group coding can work is if everyone is working on their own module, and that it is setup in a way that none of them have to be done in a certain order or even work together.

For example for my game server we are two devs. One might work on a determined list of mobiles and have the abilities setup, while I work on a core system that has nothing to do with those mobiles. I can add his code at any time and it will work and not depend on my code that may be half done, and same goes for my code, I can add it in before his and wont break anything.

But when you have multiple people working on parts that all depend, you can run into issues. i'm considering getting another coder but we're waiting till we start up again (we took a long break) so we can decide what to give to the new coder.

But yeah sounds like a crappy situation. The more people you add and the more complex the system is, it can really turn into a mess.
 
i took an animation class last fall where it was 12 people in one room. one of the
guys caught my attention because he drew a dragon, by hand, & it was a pretty good
rendition, for a quick sketch.

then he started going on about the various facets of rigging, morphing, all the various
aspects of animation ...

for i = 1 to 200
"oh that is so cool ! i want to learn that"

incessantly. meanwhile i'm trying to learn a detailed crowd simulation feature, finding
it difficult to concentrate. first i wore ear-plugs. then i brought in some sound-deadening
headphones to wear over the ear-plugs.

idle chit-chat can make it hard to get the real work done.
 
The only time group programming works well is when the project can be broken up into pieces that have very little to do with each other, or interoperability pieces (ex. data layer) are developed and finalized before the group programming beings. When different programmers start working on tightly coupled pieces, you're always going to run into conflicts, whether they be duplicated work, contradictions in code, or branches that take more time to merge than the original coding.
 
Originally posted by: Markbnj
Pair programming is ok, but mostly just a way to give management types the warm and fuzzies. The situation OP is in is just stupid.
Click to expand...

Ever do pair programming in practice? It's just as effective (better in my experience) than doing peer reviews.
 
Originally posted by: IHateMyJob2004
Originally posted by: Markbnj
Pair programming is ok, but mostly just a way to give management types the warm and fuzzies. The situation OP is in is just stupid.
Click to expand...

Ever do pair programming in practice? It's just as effective (better in my experience) than doing peer reviews.
Click to expand...

Yes, and I actually don't mind it, especially if I like the person I'm working with. But I still think it's largely a gimmick.
 
Pair programming works ONLY if both the programmers have nearly the same amount of skill. Otherwise, it'll end up being a situation where one of the programmers ends up contributing little.

Originally posted by: Markbnj
Yes, and I actually don't mind it, especially if I like the person I'm working with. But I still think it's largely a gimmick.
Click to expand...

Mark, I understand why some people consider pair programming to be a gimmick, but IMO, the ONLY real benefit of pair programming is that the resulting code is more formalized, without any 'artistic' value from an individual developer.

To the OP, your boss must have read/heard somewhere about the 'great' benefits of programming as a team. Approach him with statistics. Do NOT point out that his code is faulty. Instead, show him that you guys produced more working code with your old way of programming and how little you are accomplishing now.

I think it will be best to bring someone else along with you, to verify your statistics.


A silly thought just occurred to me. 😉 Perhaps your boss wants to save on the electricity bill by having all the programmers use just one PC ? 😛
 
Mark, I understand why some people consider pair programming to be a gimmick, but IMO, the ONLY real benefit of pair programming is that the resulting code is more formalized, without any 'artistic' value from an individual developer.
Click to expand...

With all due respect that can't possibly be true. I'll readily grant the one true benefit of programming in pairs: you find more bugs earlier when someone else is looking at the screen with you. If absence of bugs is what you mean by "artistic value" then ok.

But of course this is true in any profession. If I put two cabinetmakers on every job, or two toolmakers, or two electricians, then I'll probably get fewer errors. It's something to celebrate, I guess, if the state of our business is so abysmal that the only way we can possibly make things work right is to put two programmers on every task.

 
Originally posted by: Markbnj
Mark, I understand why some people consider pair programming to be a gimmick, but IMO, the ONLY real benefit of pair programming is that the resulting code is more formalized, without any 'artistic' value from an individual developer.
Click to expand...

With all due respect that can't possibly be true.
Click to expand...

I agree that finding bugs IS a big benifit of pair-programming. (I missed that, sorry)

But please consider, any big organization worth it's salt will have their own internal coding styles. Some people may consider the process a pain, but in the long run, for the organization, if all the code is written consistently, it makes it easier to debug/update years later by a new programmer.

When you have a single (but good) programmer working on a task, he/she may not code to the organizations standards. And in some cases, if the code works fine, the manager may overlook the standards, as long as it's close enough.

In such a scenario, pair programming helps a lot. What might be considered easy to understand by one programmer, could be an enigma to another. By having them both agree to commit to the same code, you have a MUCH better chance of enforcing coding standards in an organization.

From what I know that's one of the major benifts of pair programming. I must confess though, I've never done it properly myself. But I hear from those who do.
 
Ah, so it's even worse than I thought: we need two programmers to catch bugs and keep people from wandering away from the corporate coding standard.

The real issue is that programmers are half as good as they were twenty years ago. In ten years they will be 1/3 as good and you'll need three.
 
Originally posted by: chronodekar
Originally posted by: Markbnj
Mark, I understand why some people consider pair programming to be a gimmick, but IMO, the ONLY real benefit of pair programming is that the resulting code is more formalized, without any 'artistic' value from an individual developer.
Click to expand...

With all due respect that can't possibly be true.
Click to expand...

I agree that finding bugs IS a big benifit of pair-programming. (I missed that, sorry)

But please consider, any big organization worth it's salt will have their own internal coding styles. Some people may consider the process a pain, but in the long run, for the organization, if all the code is written consistently, it makes it easier to debug/update years later by a new programmer.

When you have a single (but good) programmer working on a task, he/she may not code to the organizations standards. And in some cases, if the code works fine, the manager may overlook the standards, as long as it's close enough.

In such a scenario, pair programming helps a lot. What might be considered easy to understand by one programmer, could be an enigma to another. By having them both agree to commit to the same code, you have a MUCH better chance of enforcing coding standards in an organization.

From what I know that's one of the major benifts of pair programming. I must confess though, I've never done it properly myself. But I hear from those who do.
Click to expand...

If one person can't follow the rules what makes you think two people will?
 
Originally posted by: chronodekar
Originally posted by: Markbnj
Mark, I understand why some people consider pair programming to be a gimmick, but IMO, the ONLY real benefit of pair programming is that the resulting code is more formalized, without any 'artistic' value from an individual developer.
Click to expand...

With all due respect that can't possibly be true.
Click to expand...

I agree that finding bugs IS a big benifit of pair-programming. (I missed that, sorry)

But please consider, any big organization worth it's salt will have their own internal coding styles. Some people may consider the process a pain, but in the long run, for the organization, if all the code is written consistently, it makes it easier to debug/update years later by a new programmer.

When you have a single (but good) programmer working on a task, he/she may not code to the organizations standards. And in some cases, if the code works fine, the manager may overlook the standards, as long as it's close enough.

In such a scenario, pair programming helps a lot. What might be considered easy to understand by one programmer, could be an enigma to another. By having them both agree to commit to the same code, you have a MUCH better chance of enforcing coding standards in an organization.

From what I know that's one of the major benifts of pair programming. I must confess though, I've never done it properly myself. But I hear from those who do.
Click to expand...

That's what code reviews are for.

For every single checkin, even scripts and build files, diffs are sent out to the appropriate mailing lists so implementation and style can be reviewed and questioned.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top