How to convince my boss to join programmers into pairs or even teams?

Question

Welcome Our company has 4-6 programmers, each one working on 1-2 projects, and few more awaiting in schedule. Problem - from my point of view - is as long as I work here I work alone - so do all others.

I tried to talk with my boss that I want to work with others, exchange knowledge, learn from each other. He understand me, but also states that there is no big project to put more than one programmer into. There is possibility to have big project in nearly future, but first we must have those not yet started. Other problem is even if one of us finishes project, the other will be in the middle of his - so the first one will get another "small" project.

We started doing some internal trainings to share knowledge, but it's not the same as some challenging project did together with others.

What should I point to my boss trying to convince him to try harder to form a programmers team?

Answer 1

Do a bit of reading about pair programming.

Let's suppose 2 programmers working on a project means that project is finished twice as fast. Then it doesn't matter whether your programmers are working together or working alone - the same number of projects get completed in the same amount of time. Of course it isn't always as simple as this, but there are other things to think about:

A big benefit of programmers working together is that more programmers are "qualified" to work with the code later on (if you want to add features or fix bugs, for instance), which can be very helpful if one programmer has left the company, or is busy with something else.

Of course when programmers work together, they complement each other, thinking of better solutions than they would alone, and catching each other's bugs.

And of course it's (usually) more fun, meaning better morale and (hopefully) higher productivity.

Answer 2

Maybe you shouldn't be pushing your boss. Try working informally with your peers. You probably won't be contributing code to each others projects, but with a positive attitude people love to share ideas. Swap design documents and ask for feedback. Show your coworkers a sketch of some UI you plan to build, and ask them how they would use it to accomplish tasks your software is intended for (as a lightweight usability test).

Answer 3

You will also work more effectively if you work in pairs. If you have a colleague at your side, you will probably not be distracted by things like private email, Facebook, Twitter etc. Another good point is that you are less likely to get stuck on a problem if you are working in pairs.

Answer 4

Another big win-situation with pair programming are when a programmer quit he does not take all knowledge about the project with him. Also true for when someone get sick.

Answer 5

I agree with Artelius points and just want to add that if two people are familiar with code then people are better able to take vacations.

It was a big problem in my old job but as soon as we paired up I was able to take vacations without looking at my emails constantly.

In my experience pairing up also translates into better code and a less isolated workplace.

We almost never did the XP pair programming were two people share the same computer and most of the time we weren't working in the same project at the same time. But we made sure that no one was the only one that knew how a piece of code worked.

Answer 6

I have to agree with Steven on his comment. I think the 2 biggest problems in the workplace apart from lack of skills and knowledge are low moral and procrastination. Working in groups may add a social element to the mix which from your employers point of view may be bad but it helps boost moral. Working in groups allows developers to work on each others strengths as no developer is perfect at his craft or knows everything. Procrastination is largly reduced when it is not just you.

Eg: How many people say they are going to do something at regular intervals like going to gym? They start off going 3 times a week and after the first month they probably don't even go anymore and is not as much fun as when he/she started, now take the same situation/person but add someone else, they go together they train together, the attatude towards gyming will have changed(positively). The tendancey to just stop/quite will not be as high and you are guarenteed that the results will be far greater.

Answer 7

I had this same problem at my former job... it's not easy to overcome. But the best you can do is show the management-side benefits. (meaning, show benefits in their terms in a simple list).

1. If someone gets sick, the other dev knows where things are and can (if nothing else) explain what needs to be done.

2. Developers will sharpen each other's skills (faster developer skill-growth).

3. Much less likely to have bugs. I know when I have someone else using/looking over my code they can usually spot something that I missed and vice/versa.

If that doesn't work, you can always threaten that you'll all quit... ... ... no, don't do that :)

Answer 8

This decision depends from management in a first place. Or better say its availability. You can try working in as a team without official decision. But it is hard and requires some extra leadership and other teamwork specific practices. If your manager is not the one to provide those skills and your department does not have other people having those necessary skills to then management will hesitate to change toward better teamwork.

Answer 9

Testing: assign a black hat to each project.

Some of the best testers are those that really understand software production. They know how to break software, they can read the source for inspiration, they have the software and bytecode inspection tools that will help them seek out the weak spots.

From management's point of view, you'll have delivered a variety of benefits:

1. Better code: testing and the decision process of "what do we have to fix?" is good for the product.
2. Cross-training: if you get into a codebase in order to find out how to break it, you can't help but learn about it.
3. "For-free": black hat can be a part-time job. Just because someone is assigned to break another project, they don't have to stop working on their day job.
4. Morale: breaking other people's code can be a lot of nasty fun.

None of the above are an immediate team-builder. Frankly, if you want a team, you have to do a lot of messy people things. That said, at least you'd have more than one person working together at a time.