Paired Programming and Test Driven Development

posted by Christopher on October 20, 2009

{{chris}} I recently came across two very interesting programming approaches which I wanted to share with you. First, Paired Programming puts two programmers together to develop a single solution. Second, Test Driven Development has a developer produce their Tests first and then program to ensure their software meets the tests. Both are very interesting approaches and I go into a little more depth on each of them for you.

Paired Programming

Paired Programming has been around for a long time now so it’s nothing new. However it is gaining popularity lately because of the benefits it has. Many project managers would overlook the opportunity because of the perceived added cost to a project of having two programmers do the job that one could easily accomplish. What they are overlooking though is the synergy that develops between the programmers as they work together to solve a particular problem – both working from the same workstation. They are not working in parallel – but rather working together to solve a problem.Â The old adage of two heads are better than one applies here. While one developer can be writing code – the other can be writing tests and brainstorming solutions. They can the switch off giving each other a turn at each activity. Development can be done quicker and better.

Some resources about paired programming include:

Wikipedia has a nice overview of the benefits and drawbacks of Pair Programming: http://en.wikipedia.org/wiki/Pair_programming
Menlo Innovations: http://www.menloinnovations.com/freestuff/whitepapers/pairedprogramming_qanda.htm
Computer Science Teachers Association: http://blog.acm.org/archives/csta/2009/10/the_benefits_of.html

Test Driven Development

Kent Beck is credited with reviving / adding new life to this style of Extreme Development where a developer first starts with producing a very basic test case which will fail because no code has been written. Then upon writing some code to pass the test case writes another test case and always refactoring the code to pass the test cases they are producing. Once all test cases are written – the code too amazingly passes the test cases! The tests themselves are always small and precisely defined and have true or false steps allowing the developer to easily write code to pass them.

This style of development is very productive and keeps the developer focused on producing only the code necessary to pass the tests. This ensures the program is very focused and does not go off in the weeds. It also reduces the number of “bugs” which has a tangible cost savings further along the software development cycle.

Some resources about Test Driven Development include:

Wikipedia: http://en.wikipedia.org/wiki/Test-driven_development
Wikipedia Kent Beck: http://en.wikipedia.org/wiki/Kent_Beck
AgileData.org: http://www.agiledata.org/essays/tdd.html
Test Driven.com: http://www.testdriven.com/modules/news/
MSDN: http://msdn.microsoft.com/en-us/library/aa730844(VS.80).aspx

I hope you find these resources interesting and of value to you and your business. I know they’ll force you to think differently about programming – if that happens, I’ve done my job!

Share and Enjoy:

Comments (12 Comments)

Carla
November 4, 2009

It was worth sharing the info
small business resources
November 9, 2009

I have bookmarked this page.Thanks a lot for the great article.Looking forward for more!
Computer Service Sydney
November 11, 2009

In my experience of leading teams I’ve always found designing at the keyboard to be more expensive than at the whiteboard. What is important is to know when to stop the whiteboard work and start coding. Experience will tell you when you are wasting time designing and it is time to try something out in code.
perfume spot
November 19, 2009

When you’re the observer, read the code that the driver is writing as he or she writes it. Your job is code review. You should pay total attention, aiming to let nothing get by you. Think about possible bugs, larger issues, and ways to simplify or improve the design. Bring up errors and code that you find unreadable right away. Wait until the current tiny goal is done to bring up larger issues and ideas for design improvement. Jot these later tasks down so the driver can stay focused on the present tiny task. For example, if you see that the current code fails to account for a null input, write down on a piece of paper, “Add unit test for null input.”
DIY car hire
November 19, 2009

In thinking back over a couple of experiences in team coaching and organizational change, I’ve begun to realize that there is more to success than just spinning up one or two “hyperproductive” teams. One experience was at the first company where I learned agile methods in 2002, and the other was earlier this year, 2009. In both cases, we achieved astonishing success in creating one team or a small group of teams that performed far outside the norm for their respective organizations.
neelmoney dot com
November 24, 2009

Sometimes working with complected team make me boring. hey No way to fill like CEO. I am the programmer and developer as own . this gives me flexibility and many paired to each way.
Boquete Panama Hotel
November 25, 2009

Great information. I am subscribing your blog
Tie Racks
November 26, 2009

Thanks for sharing the programming part in your blog i really found this details much important as i deal with it………
So thanks once again for information you had provided..:)
payal
December 3, 2009

Thanks for sharing very useful information.
huseyin
December 14, 2009

Thanks for sharing very useful information.
Divx indir
February 26, 2010

Thanks good article
Sagopa Kajmer
March 7, 2010

Good post.Very good.

Spark Internet Marketing

Paired Programming and Test Driven Development