Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Pair Programming and TDD

Tom Wilson
October 22, 2011

Pair Programming and TDD

Why we do Pair Programming and TDD at @jackhq

Tom Wilson

October 22, 2011
Tweet

More Decks by Tom Wilson

Other Decks in Programming

Transcript

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

    [email protected] • @jackhq - twitter.com • twilson63 - github.com Saturday, October 22, 11
  2. 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
  3. 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
  4. There are 10 types of people in the world -

    those who know binary Saturday, October 22, 11
  5. There are 10 types of people in the world -

    those who know binary and those who have friends Saturday, October 22, 11
  6. 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
  7. I can’t imagine not pair programming every day. -- JRS

    Developers Saturday, October 22, 11
  8. Did you hear about the Coder that got stuck in

    his shower for a week? Saturday, October 22, 11
  9. 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
  10. 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
  11. Programmers using pure TDD on new ("greenfield") projects report they

    only rarely feel the need to invoke a debugger. -- Wikipedia Saturday, October 22, 11
  12. 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
  13. The tests may therefore share the same blind spots with

    the code -- Wikipedia Saturday, October 22, 11
  14. The tests themselves become part of the maintenance overhead of

    a project. -- Wikipedia Saturday, October 22, 11
  15. First Major Prj • 3 years of Development • 15

    Developers • 90 hour work weeks • No Tests and lots of meetings! Saturday, October 22, 11
  16. 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
  17. 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
  18. Failure is not an option. It comes bundled with your

    Microsoft product. Saturday, October 22, 11