Tag Archives: pair programming

February 5, 2010

Pair Programming as a Motivator

By Paulo "JCranky" Siqueira

Everyone has ups and downs. Maybe a fight with a significant other, or a problem with family, it doesn’t matter, brought you down. I went through something in this line a while ago, although for a completely different reason. But why am I talking about this?

People who read my blog for sometime now probably know I like agile software development. One of the strategies it uses (from eXtreme Programming) is pair programming, and I talked about it a long while ago here.

Now, to the point. What I found out is that, at least for me, pair programming has one more advantage that I was not used to pay attention to: it can help you get motivated. Just having to explain my ideas and having to listen to my pair’s ideas goes a long way in terms of motivation. As I love what I do, this conversation “thing” helps me get back to reality and be productive.

If you cannot do pair programming constantly, what I would suggest you should do is, as soon as you’re feeling you’re not doing as well as you could, do some short pairing. Even if at least for an hour or so, it should help renovate your thoughts.

Now get your hands dirt, try it out and post a comment with your opinion! =)

1 comment   |  tags: , , , , | posted in agile

January 9, 2009

Software Quality and Agile

By Paulo "JCranky" Siqueira

Often when we talk about agile software development, we mention how important quality is. In this post, I’ll run quickly through some thoughts and practices on how agile tries to guarantee this so-called higher quality.

When I first started using agile (eXtreme Programming in my case), one of the things that called for my attention the most was its focus on Accuracy and in avoiding Waste. This means that when developing software using an agile methodology, we always try to build exactly what the client/user want. Nothing less, nothing more. Having developed some things before using methodologies closer to traditional ones, I was urging for someway to stop doing useless work and wasting time (diagrams that would never be touched again anyone?). Agile seemed to be a good bet.

But this all is a little bit abstract. Like I said here, this is just saying that we will try to bring the most value to the client. Now looking into something more practical, there are some interesting things that we can use in a daily basis that also help us improve software quality, among them:

  • Pair Programming: two developers, instead of one, work together to solve problems. I talked previously about this here.
  • Pair Rotation: to avoid that the pairs get “accustomed” to its pair, we can constantly change the pairs that works together. This also helps leveling up the team knowledge and experience.
  • Tests: this is another invaluable practice that should be done in a daily basis. There is too much to sum up in a few lines. I’ll just mention two types of tests: unit and acceptance. We use unit tests to make sure the each individual feature of a system is working, and acceptance tests to guarantee that the whole system is ok, from a perspective similar to what the actual users have.

That’s it for now. I have a few other topics to write about in the pipeline, but if you have any ideas / suggestions for things you would like to see here, please don’t exitate to post a comment!

Bye!

Leave a comment   |  tags: , , , , | posted in agile

September 7, 2008

Pair Programming

By Paulo "JCranky" Siqueira

This is the way it works: every time anyone in the team needs to develop something, whatever it is, she does it in pairs. This means that two developers sit together and work to solve the same problem. Having done it for some time, and being the coacher of a team that does it, bellow are some considerations about this subject.

With pair programming, we put in practice the principle of “Collective Code Ownership” – which means that there is no such thing as an owner for any part of the project’s code or related artifacts. This is mainly possible because the developer is not coding alone. She always (or almost always) has someone else working together on the same code, on the same functionality.

As it is said, “Two heads are better then one”. Pair programming is a practice where math doesn’t work quite well because 1 + 1 > 2 here. This means that the value created by two programmers working together is greater than the one created by each of them separately and then summed up.

Pair programming also brings a lot of other benefits, both for the project and for the developers involved. For instance, the code quality rises. It gets better design and fewer bugs that it would end up having if it was developed by a single programmer. And the code ends up getting reviewed all the time.

On the other hand, despite maybe being counter-intuitive, the productivity also rises. Two people together can find a better solution for a problem much faster. How many times have you asked for an opinion from a co-worker that helped you with that terrible problem quickly? Now imagine that you have the co-worker available to help you all the time.

For the developer, pair programming is also great because it stimulates his professional growth. With pair programming, a developer has the chance to learn from its pair’s experience. At the same time, she also has the opportunity to transmit some knowledge. This learning is much faster than reading, for example. And as they say, teaching is the better way to learn.

Unfortunately, it is not always possible to do pair programming. A few things might prevent doing it:

  • you mighty be the only one developer in a small project;
  • there might be an odd number of developers (and thus someone must stay alone);
  • or, in the worst scenario, the company won’t allow you to do it.

Or maybe any other reason I can’t think up now. Anyway, it is always worth the effort trying to do pair programming so, if you can, go for it!

3 comments   |  tags: , , | posted in agile

Follow

Get every new post delivered to your Inbox.