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!
