Paired Programming and Test Driven Development
October 20th, 2009 by hbond{{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!
It was worth sharing the info
I have bookmarked this page.Thanks a lot for the great article.Looking forward for more!
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.
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.”
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.
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.
Great information. I am subscribing your blog
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..:)
Thanks for sharing very useful information.
Thanks for sharing very useful information.
Thanks good article
Good post.Very good.