Pair Programming, TDD and other impractical things


Published on

"Why should we write our tests first? Isn't that going to slow my development?" "What? Assigning a single task to 2 developers? How is that efficient? What a waste of resources!" "Look, in the perfect world your advises are great, but I have a project to finish here." In this talk Marcello explores efficiency in contrast to effectiveness. He looks into how practices, traditionally accepted as efficient, sometimes turn out to be less effective than a few "impractical" things he has come across.

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Pair Programming, TDD and other impractical things

  1. o th er D a nd TD min g, in g s ir P ro gram c a l thPa rac ti im p by @_md
  2. I coach teams intocollaborative software development
  3. software is about people
  4. software is not as much about Øs and 1sØ111ØØØ1ØØ111ØØØ1ØØ111ØØ111111ØØ111Ø111ØØØ1ØØ111ØØØ1ØØ111ØØØ1ØØ111ØØØ1ØØ111ØØØ1ØØ111ØØ111111ØØ1111111ØØØ1ØØ111ØØ1Ø1111ØØ111
  5. as it is about Xs and Ys
  6. { use itit’s people who
  7. { use it develop itit’s people who
  8. { use it develop itit’s people who order it
  9. { use it develop itit’s people who order it accept it ...
  10. coding is not as hard as collaborating
  11. 1 impractical thing #1Listen to your customer
  12. Customers don’t know what they wantCustomers change their mind all the time Customers are too busy to get involved i mp ra ct ic a l If I listen... BANG! Scope creeps in! Customers want everything!I keep adding and removing must haves
  13. why do I need to listen?can I please just sit and write my code?
  15. “Nobody wants a washing machine just tohave a machine, but to have clean clothes.” – Jon Sundbo
  16. When to listen?
  17. Continuously
  18. project mission sprint planning sprint vision sign off retrospective
  19. project mission sprint vision sprint planning sign off retrospective First create a project mission based on business goals... not scope!
  21. impact map WHAT HOW WHAT WHO WHY HOW WHAT WHO HOW WHAT[Adzic 2012]
  22. project mission sprint vision sprint planning sign off retrospective Include a sprint vision (example) workshop in every iteration, prior to sprint planning
  23. Goal of sprint vision (example) workshopTo define sprint vision and acceptance criteria
  24. As an <actor> I can <behaviour> So that <value> Given <pre-condition> When <act>product backlog Then <expectation>
  25. What if the customer isn’t available?
  26. proxy
  27. project mission sprint vision sprint planning sign off retrospective Write the form for the comment area 1/2 dproduct backlog sprint backlog
  28. project mission sprint vision sprint planning sign off retrospective
  29. project mission sprint vision sprint planning sign off retrospective
  30. 2 impractical thing #2Test Driven Development
  31. How can I test something I haven’t done yet? It takes time to learn TDD The team is not confident they can do it i mp ra ct ic a l It’s legacy. The code is untestable Customer is not paying for tests My manager doesn’t give me time to test
  32. requirements analysis design code test deploy
  33. requirements analysis9 m on th design code s test deploy
  34. most of the cost in software comes fromfeedback delay
  35. user stories conversation test design code deploy increment
  36. user stories conversation test 20 min design code deploy increment
  37. testrefactor code
  38. testArrange Act Assert
  39. testArrange Write the code Act you wish you had Assert
  40. codeChange the message or get it green, not right
  41. refactorNow get it right. Without modifying behaviour.
  42. refactor1. All tests run and pass2. Remove duplication3. Remove opacity4. Remove complexity
  43. results in code1. Testable2. Modular3. Expressive4. Simple
  44. lack of tests breaks inner quality1. Viscosity2. Immobility, Rigidity, Fragility3. Unreadable4. Complex
  46. Refactoring: changing the structure not the external behaviour – Fowler, 99
  47. There is no refactoring without testsThere is no testing without refactoring
  48. “Code is a representation of design” – Jack W. Reeves
  49. refactoring === design
  50. Agile without TDD* is like cinema without popcorn*or similar practice
  51. 3 impractical thing #3Focus on Quality over Schedule
  52. There is no time for quality The budget doesn’t cover quality It’s a very simple project i mp ra ct ic a l We’ve done it thousand times Quality is vague, deadlines are real!Do the needful now. We’ll come back to it later
  53. Outer Quality Quality is like onionsInner Quality
  54. Outer QualityWorks as expected Built efficientlyLooks like expected Focused on goals
  55. Inner Quality Testable ModularExpressive Simple
  56. Lack of Outer Quality Causes...
  57. Rework Going over budget Bugs Low MoraleMissing deadlines Project abortionUnusable systems Relationships deteriorate
  58. But what causes poor Outer Quality?
  59. Lack of automated acceptance tests Lack of customer involvementTeam not focused on Project Mission Lack of Inner Quality
  60. Lack of automated acceptance tests Lack of customer involvementTeam not focused on Project Mission Lack of Inner Quality
  61. Focus on schedule FearLow morale Haste Re-work
  62. Focus on quality Align with goalsPride Do the right thing Achieve
  63. How do you ensure Outer Quality?
  64. Example workshops Automate acceptance testsHave a sprint vision statement Sign off during Sprint
  65. How do you ensure Inner Quality?
  66. TDD CI (tests, static analysis) from day onePair Programming or at least Peer Review
  67. 4impractical thing #4Pair Programming
  68. 2 resources 1 task? do the math! Why isn’t everyone else doing it?They will just chat and not get anything done i mp ra ct ic a l I do all the work the other guy just looks How do you track the time per task? Geeks don’t want to talk to other people
  69. 2 developers sharing a screenworking on the same task
  70. What is Pair Programming about?
  71. AddictionCompany Feedback Jon Jagger’s Principles of ImprovementVisibility Provocation Success
  72. Pair programming is about improving faster
  73. One of the few proven agile practices “Strengthening the case for pair programming”
  74. Should pairs be kept together?
  75. Who to pair with who?
  76. Important stuff✓ Focus on the code✓ Use the test list✓ Don’t “I-show-you” your pair✓ Time box decisions
  77. How do I learn this?
  78. 5impractical thing #5 Code Katas
  79. Who’s paying for that? What? Write code and delete it? What? I am already working 9 to 5 i mp ra ct ic a lSolving a problem that has already been solved? I am committed to a sprint I have a release, can’t join you today
  80. “Adults don’t think their way into a new way of acting. They act their way into a new way of thinking” – Richard Pascale
  81. ✓ 1 hour every week✓ developers go to a meeting room✓ do TDD in pairs✓ 20 mins each round✓ at the end of each round:✓ delete the code and swap pairs
  83. “We have a great tool in this language. We can kill it by making a mess. We can kill it by beingarrogant. We can kill it by ignoring the enterprise.”
  84. “Be daring, be different, be impractical, be anythingthat will assert integrity of purpose and imaginativevision against the play-it-safers, the creatures of the commonplace, the slaves of the ordinary.” ImpracticalQuote
  85. Marcello Duarte I work hereI contribute here I tweet here @_md
  86. Thank you !
  87. Questions or Comments? looking for a new challenge?