Pair Programming and TDD

Transcript

1. Pair Programming and Test Driven Development BarCampCHS Saturday, October 22,

   11

2. WHOAMI • Tom Wilson • President/Founder Jack Russell Software •

   [email protected] • @jackhq - twitter.com • twilson63 - github.com Saturday, October 22, 11

3. Programming is Hard Saturday, October 22, 11

4. What is pair programming? Saturday, October 22, 11

5. Saturday, October 22, 11

6. Pair programming is an agile software development technique in which

   two programmers work together at one workstation. One, the driver, types in code while the other, the observer (or navigator[1]), reviews each line of code as it is typed in. The two programmers switch roles frequently. --Wikipedia Saturday, October 22, 11

7. Cost & Benefits Saturday, October 22, 11

8. Saturday, October 22, 11

9. • Pair Speed Advantage • Pair Defect Advantage Saturday, October

   22, 11

10. The potential speed and defect advantage of Pair Programming are

    usually explained as follows. Pair programming allows developers to share their ideas im- mediately. This allows to get down to solutions more quickly and also helps to eliminate defects early. In addition, Pair Programming leads to an ongoing review of the program code by the second -- Frank Padberg and Matthias Muller Saturday, October 22, 11

11. There are 10 types of people in the world -

    those who know binary Saturday, October 22, 11

12. There are 10 types of people in the world -

    those who know binary and those who have friends Saturday, October 22, 11

13. Conclusion Saturday, October 22, 11

14. Given that a short time to market is decisive for

    the success of a project, adding developers to form programmer pairs can speed up the project and increase its business value despite the increased person- nel cost. This is due to the fact that programmer pairs can be expected to have a higher productivity and code quality as compared to single programmers. Saturday, October 22, 11

15. Saturday, October 22, 11

16. 2 Brains + 1 Problem = Solid Solution Saturday, October

    22, 11

17. What about the developers? Saturday, October 22, 11

18. I can’t imagine not pair programming every day. -- JRS

    Developers Saturday, October 22, 11

19. Did you hear about the Coder that got stuck in

    his shower for a week? Saturday, October 22, 11

20. The instructions on his shampoo said: Lather, rinse, repeat. Saturday,

    October 22, 11

21. If at first you don't succeed; call it version 1.0

    Saturday, October 22, 11

22. What is Test Driven Development? Saturday, October 22, 11

23. Test-driven development (TDD) is a software development process that relies

    on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.[1] Saturday, October 22, 11

24. Benefits Saturday, October 22, 11

25. Test-driven development offers more than just simple validation of correctness,

    but can also drive the design of a program. -- Wikipedia Saturday, October 22, 11

26. Programmers using pure TDD on new ("greenfield") projects report they

    only rarely feel the need to invoke a debugger. -- Wikipedia Saturday, October 22, 11

27. TDD can lead to more modularized, flexible, and extensible code.

    -- Wikipedia Saturday, October 22, 11

28. How many programmers does it take to change a light

    bulb? Saturday, October 22, 11

29. None. It's a hardware problem. Saturday, October 22, 11

30. Costs Saturday, October 22, 11

31. Test-driven development is difficult to use in situations where full

    functional tests are required to determine success or failure. -- Wikipedia Saturday, October 22, 11

32. The tests may therefore share the same blind spots with

    the code -- Wikipedia Saturday, October 22, 11

33. The tests themselves become part of the maintenance overhead of

    a project. -- Wikipedia Saturday, October 22, 11

34. Windows: Just another pane in the glass Saturday, October 22,

    11

35. My Experience Saturday, October 22, 11

36. First Major Prj • 3 years of Development • 15

    Developers • 90 hour work weeks • No Tests and lots of meetings! Saturday, October 22, 11

37. Second Major Prj • 10 - 12 Developers • 2

    years - Parallel Release • Better Organized Architecture • No Tests • Lots of Meetings! • Lots of QA and Debugging! Saturday, October 22, 11

38. JRS Last Big Prj • 3 Dev Teams (6 Developers)

    • Less 6 mos to Beta • Few Meetings • Ship Code Everyday • Over 70% Code Coverage Saturday, October 22, 11

39. Why? Saturday, October 22, 11

40. Code is Art! Saturday, October 22, 11

41. Confident Code! Saturday, October 22, 11

42. Pair Programming + TDD = Quality Saturday, October 22, 11

43. Writing code for the future reader! Saturday, October 22, 11

44. Failure is not an option. It comes bundled with your

    Microsoft product. Saturday, October 22, 11

45. Research Saturday, October 22, 11

46. ScreenCasts Saturday, October 22, 11

47. Saturday, October 22, 11

48. Thank You http://www.charlestonruby.org/ http://charlestonjs.org Questions Saturday, October 22, 11