• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Memir

Pair Programming Revisited

10 posts in this topic

So a little background about me. I've been developing software in the back bedroom for many years, along with my brothers. Worked for a dozen different companies in varied team sizes, on many successful projects over the past 8 years. So I would consider myself pretty experienced (Games, Applications, Web Applications, C++/Assembly/Flash/PHP etc. you get the idea).

 

So now, on my most recent contract. The most highest paying one I've ever had, a very important UK project, but arguably one of the more easier projects I've been involved with, and working alongside generally less talented developers than most of my previous roles. I've come across this new buzz word called "Pair Programming" (PP).

 

Now I'm not sure how I've managed to avoid PP for so long in my career. But apparently, PP is not only the solution to improving code quality, but is apparently the only way any good software was ever built, and any project that has been successfully developed without PP is a miracle.

 

(I personally think considering the importance of the project we're working on. We should take the hiring process more seriously and hire quality developers i.e. nerds. over hiring 'politically savvy' sub-standard developers and coming up with various processes to improve their output on such an important project.)

 

*end of rant*

 

Now looking at this objectively. If I do a google search for PP. I can see a lot of studies that report PP to be more productive, improve code quality, and reduce bugs. I can't understand this when most programming tasks are trivial (or at least seem trivial to me). Once the architectural aspects of a task have been discussed. A good programmer should be competent enough to implement the architectural specification. Then once implemented, another developer should be able to code-review it, just to pick up any small programming mistakes (not architectural mistakes as that has been cemented before coding).

 

Looking back on an old topic on GameDev.net about PP, seems mostly negative views on it. Perhaps GameDev.net developers have a different view, or perhaps the majority of developers have a different view, and these studies are skewed?

 

I think the problem is that in most projects. There are 10-20% of programmers that are truly talented and motivated. They are responsible for the core, and even much of the bulk of any software project. The other 80-90% lack talent and/or motivation and don't contribute much (especially when you factor in the number of bugs, and hacks they introduce). PP works well for them.

 

"I find with PP I'm much more productive" - Perhaps thats because when you work alone, you're not focused, and browse the internet most of the time. Or perhaps thats because you're not as good as your pair, so your output is being raised (perhaps your "better-half" is less productive - assuming he is motivated on his own).

 

"I find with PP we spot errors like semicolons, and brackets more quickly" - Missing semicolons and brackets is simply unacceptable. If you make these silly mistakes shame on you. If it takes you a long time to spot them after the compiler has helped you find the line, then well I think you need to find new profession.

 

"I find with PP we come up with different solutions to solve a problem" - No, discussing how you're going to tackle a task gives you different solutions to solve a problem, this is architectural design. If you have discussed a problem properly before writing a single line of code. Then there are very few ways of implementing the code, especially once you follow an agreed upon coding standard/convention.

 

"I find with PP I learn lots" - You can also learn a lot just by reading or reviewing the code, instead of interrupting someone's train of thought. I actually find I learn much better by playing with the code, figuring out how things work and developing a complete map of the code base, instead of relying on someone else to tell me all the answers.

 

"After a long day with PP I feel satisfied" - This is very interesting. Considering programmers tend to be introverted. I find programming solo, very therapeutic, and I can code into the evening with people reminding me to go home. Makes you feel pumped and really good about yourself. With PP, I start to get a headache in the afternoon, and just want to go home. It's painful, emotionally draining. - I don't consider myself that introverted, I enjoy talking to people, helping them with problems, and chatting up the female staff. I just don't enjoy pair programming. I feel like an impatient kid jumping up and down watching a programmer slowly write code, and constantly correcting them, and trying to convince them to do it my way.

 

It probably is a case of talent and motivation. I've done a lot of pairing with others over the past 6 months. But when I think of all the times when I've paired with other people. I've felt that it would've been of better quality on my own (they disregarded certain safer techniques that I would've used), and done quicker (they seemed tired, and not properly focused). While they felt that they produced better quality code with me, and that they were productive.

 

(Weak Programmer + Good Programmer) / 2 = Average Programmer.

(Lazy Programmer + Motivated Programmer) / 2 = Average Programmer.

 

In closing. I have a habit of checking the git blame (or svn annotate) whenever I see some pathetic excuse for code (dirty copy and paste, badly named variables, not following code conventions, lazy hacks etc.). So I can tell the programmer what I think of his work. However, many a time, I've done this, and to my surprise I discover that the work was paired on (in the comments we mention the initials of who we paired with on the task). So I'm not convinced that pairing is the solution to improving code quality. Finding decent programmers is the best solution (which requires a combination of good pay, and more importantly good interview and selection process). Perhaps our education system is swamping the software industry (especially big companies) with graduate programmers who are neither motivated or up to the standards of the older generation of back-bedroom programmers.

 

It could also be that I'm not much of a team player :D - Although I actually enjoy discussing and planning things with others. I'm just old fashioned in that I like to do the work on my own.

 

Coming soon: Quad programming, the only way real software is made.

("We tried making a hello world program, and were scratching our heads trying to find out why it wouldn't compile. My number 2 couldn't smell it. Number 3 suggested reading the error message, thats what his iPhone says. Number 4 guessed it was a pesky semi colon...")

1

Share this post


Link to post
Share on other sites

Nice wall of text :)

 

Well, I can agree, I'm also not very fond of pair programming...

I kind of think in code, and more visually then in words, and I need to write it while thinking... And evolve it until it solves the problem.

Discussing it at the same time just slows me down.

 

I'm glad to help my peers with details if they ask me, but I find that the times I've tried actual PP its not long before I grab my laptop so we can write some code in parallel.

That can be good though, but there need to be enough of a problem that there need to be some architectural discussion or something else that actually need two people two solve...

 

It can be helpful with two pairs of eyes and some discussion, when researching really nasty bugs though.

But only for a limited time :)

1

Share this post


Link to post
Share on other sites

Thanks for the responses. I would like to apologise for the wall of text in the original post. I wanted to rant, but also focus on making mostly objective. But alas I'm very passionate about programming, software and especially the currently project I'm working on, and got a bit carried away.

 

Yes, I think the problem with our project is that the chief proponents of pair-programming are the Scrum Masters (who have no technical experience, and zero programming experience). I feel that many of the developers are political brown-nosers, and don't really care about the project beyond following the Agile process & whatever the mighty Scrum Masters decide (as they are responsible for the hiring & firing).

 

They are suggesting that we should all pair 100% of the time during a sprint. I feel this is simply not practical, and is a massive waste of resources. Most programming isn't rocket science, and companies should be hiring people that are qualified to write decent code. This latter point I think is the problem.

 

The only real benefit I can see from pair programming (that can't be gained so well from code-reviews, and just calling someone over 5-10 mins to explain something to you), is that of training/mentoring someone less experienced. For this, it must be established before pairing, not who is the Driver & who is the Navigator. But who is the Student, and who is the Teacher.

 

I simply feel, and I may be wrong. I'm just the 'programmer' after all, no one tells me the big picture. That if you have a project which is so important, which you simply cannot afford to mess up. You shouldn't focus your efforts on training graduates, leave that for another team. You should be hiring the best in the industry, and let them focus on priority number 1, which is delivering a kickass product!

 

I find I can just read code to learn new ideas and approaches to problems. Only thing I learn from pairing with someone else is: How fast they type, what keyboard short-cuts they use/don't use, how often they are distracted, their thought processes. If I were the project manager, then it might be useful, as I could find out who were the effective programmers and who were not. But I could just review all the patches submitted over a period of say a week to see how much work people were doing, and the quality/complexity of the work. (unfortunately our Scrum Masters are clueless to the output of their workers, if they knew, they would almost certainly abandon Pair Programming).

 

---

 

In terms of gains to the employer. This is another interesting topic. The question over is it better to have everyone working on everything. Or people that specialise on certain components...

 

With the former: The advantage is that everyone knows a little bit about everything.

With the latter: The advantage is that everything has someone who is an expert.

 

From my experience, and my current employer has also come to the conclusion that the latter is far more beneficial.

 

In theory it's good for everyone to know about everything in case someone is busy on something else, away, or leaves the company. However, in practice this is rare. You might lose an expert every 6-12 months, depends really on the project. - I think a lot of developers leave projects because they have no attachment to it. They don't feel they own anything in the cluster-**** of components.

 

In practice what happens is that no one knows enough about any single component to be confident enough to know what will happen if you do this or that. No one has a complete mental map of any component. You can't properly work on a component, without knowing what *EVERY* line of code inside that component does. Sure you can add an extra function here, or a little bug fix there, achieving a task now. But what happens is that over time, there are lots of ugly extensions, hacks, and bug fixes, that makes the code unmaintainable, because no one can see enough of the forest to say "Hey there is already a SetTextToRed written by Jim, SetTextToGreen written by Jack, and I'm writing a SetTextToBlue function, why not just have a SetTextColor function" - of course that's a simple and obvious refactor that anyone should see, in practice they're a bit more complex than that. But these are the things that are missed when you have no component ownership.

 

The most bug-riddled code is in the code which is old, has had a lot of modifications over time, and has been worked on by a lot of people. I love git-blame, it tells an amazing story about the code you're looking at.

1

Share this post


Link to post
Share on other sites
Thanks for your replies, especially frob.

Yes I'm a very critical person, and take much time to try to criticise my own work. Asking questions such as how much work I'm doing vs how much bugs I introduce etc.

In a nutshell, the problem can be see one of two ways.

1. The management are not taking the (right aspects of the) project as seriously as they should be. Instead of hiring weak developers, and developers who have no passion beyond doing the minimal amount of work to maintain their job. They should be hiring the best in the industry. They can afford it after all. So it's a tremendous waste of resources.

2. The problem is with me. My standards and expectations of the project are in realistically high. I want a product that will dominate the industry when it's released. I shouldn't care about my work, beyond the paycheck.

I do sometimes move to position 2. But then it makes me feel soulless, that a big part of my life (work) is just a waste, an exchange of time for money. The projects which I'm most proud of are the ones where they have affected other people I.e. The masses and I can tell my friends 'I worked on that'. Makes me feel like my job had a real purpose.

For what it's worth. It's hard to accurately measure productivity in this industry. But for line count I write at least 2 times as much code as the next person. While I seldom break the build. When there are bugs found, it's very rarely my area of the code, and when it is. It's usually very trivial to fix, mostly turns out to be a requirement that hasn't yet been complete rather than a real bug.

It's real simple. I'm just a lot more experienced and faster than the others in the team. It happens.

They pay my bills & pay a lot more than my previous company (despite work being far easier). So I go with it. But I employ various strategies to minimise the pairing. Even if it means agreeing with another co worker to say that we paired on a task. Essentially lying.

If I did pair properly. I would probably quit as it's not good for my mental health. Time + pain = money is the equation.
-1

Share this post


Link to post
Share on other sites
Oh and I've worked for a dozen different companies. This is the first to advocate pairing and it's mostly confined to our team.
0

Share this post


Link to post
Share on other sites

Pair-programming is effective primarily when used with foresight in a per-case situation.

There are times when I work best alone, as should be true for all of us over half the time to varying degrees.

But in some cases I need to implement an algorithm into an existing code base and I am not very familiar with the code.  Pairing up with someone who knows the code base is quite efficient.

 

I explain and code the algorithm or feature while asking, “Now I need the part of the code that handles this,” and he or she quickly directs me there, explaining any caveats I need to know before proceeding.

 

 

As with most things, it’s usually only “purely bad” because it is not being used properly.  If utilized correctly it does have a good side.

 

 

L. Spiro

 

This particular scenario could probably be extended to cover any instance where you have a subject matter expert pairing with an implementation expert. I.E. when you have someone with significant knowledge of the problem space/domain (e.g. AI, physics, networking, etc...) and someone who is familiar with the solution space (e.g. C++, Unity, some framework or another, etc...).

1

Share this post


Link to post
Share on other sites


But I employ various strategies to minimise the pairing. Even if it means agreeing with another co worker to say that we paired on a task. Essentially lying.

 

Don't do that. 

 

If you genuinely feel that pair programming is making you less productive, take it up with your manager. Suggest some metrics by which to measure your productivity and ask for a 1 month trial period of working alone vs. working in a pair. If they agree; great, here's your chance to prove your assertion. 

 

But if they come back and say "no, we feel that pair programming is part of our team culture", then you have two choices: adapt or leave. 

 

If you really disagree with any given practice in work environment, you should absolutely say so. In fact you have a moral responsibility to your employer to do so. But if after you've discussed it with the team and people have made their decision, then you should abide by that. There's nothing worse than someone on the team poisoning the environment. If you really feel that strongly about it, then the only moral course of action is to find another job.

 

Personally, I think pair programming can be useful in certain circumstances (training a novice, working on a task that's open-ended, etc.) but yeah, for the majority of the time, it's a massive resource drag. 

2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0