Successfully reported this slideshow.
Your SlideShare is downloading. ×

Pair Programming, TDD and other impractical things

Pair Programming, TDD and other impractical things

Download to read offline

"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.

"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.

More Related Content

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 th Pa rac ti im p by @_md
  2. I coach teams into collaborative 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 it it’s people who
  7. { use it develop it it’s people who
  8. { use it develop it it’s people who order it
  9. { use it develop it it’s people who order it accept it ...
  10. coding is not as hard as collaborating
  11. 1 impractical thing #1 Listen to your customer
  12. Customers don’t know what they want Customers 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. http://www.photoree.com/photos/permalink/137988-22339026@N00 why do I need to listen? can I please just sit and write my code?
  14. http://www.flickr.com/photos/samsungtomorrow/8096115179/
  15. “Nobody wants a washing machine just to have 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!
  20. http://impactmapping.org
  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) workshop To 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 d product 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 #2 Test 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 analysis 9 m on th design code s test deploy
  34. most of the cost in software comes from feedback delay
  35. user stories conversation test design code deploy increment
  36. user stories conversation test 20 min design code deploy increment
  37. test refactor code
  38. test Arrange Act Assert
  39. test Arrange Write the code Act you wish you had Assert
  40. code Change the message or get it green, not right
  41. refactor Now get it right. Without modifying behaviour.
  42. refactor 1. All tests run and pass 2. Remove duplication 3. Remove opacity 4. Remove complexity
  43. results in code 1. Testable 2. Modular 3. Expressive 4. Simple
  44. lack of tests breaks inner quality 1. Viscosity 2. Immobility, Rigidity, Fragility 3. Unreadable 4. Complex
  45. THE CODE IS TERRIBLE!! WE NEED ONE SPRINT TO REFACTOR
  46. Refactoring: changing the structure not the external behaviour – Fowler, 99
  47. There is no refactoring without tests There 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 #3 Focus 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 onions Inner Quality http://www.flickr.com/photos/monteregina/4103317832/
  54. Outer Quality Works as expected Built efficiently Looks like expected Focused on goals
  55. Inner Quality Testable Modular Expressive Simple
  56. Lack of Outer Quality Causes...
  57. http://www.flickr.com/photos/hayeycart/5900737110/ Rework Going over budget Bugs Low Morale Missing deadlines Project abortion Unusable systems Relationships deteriorate
  58. But what causes poor Outer Quality?
  59. Lack of automated acceptance tests Lack of customer involvement Team not focused on Project Mission Lack of Inner Quality
  60. Lack of automated acceptance tests Lack of customer involvement Team not focused on Project Mission Lack of Inner Quality
  61. Focus on schedule Fear Low morale Haste Re-work
  62. Focus on quality Align with goals Pride Do the right thing Achieve
  63. How do you ensure Outer Quality?
  64. Example workshops Automate acceptance tests Have a sprint vision statement Sign off during Sprint
  65. How do you ensure Inner Quality?
  66. TDD CI (tests, static analysis) from day one Pair Programming or at least Peer Review
  67. 4impractical thing #4 Pair 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 screen working on the same task
  70. What is Pair Programming about?
  71. Addiction Company Feedback Jon Jagger’s Principles of Improvement Visibility Provocation Success
  72. Pair programming is about improving faster
  73. One of the few proven agile practices “Strengthening the case for pair programming” bit.ly/pair-case
  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. 5 impractical 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 l Solving 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
  82. http://lmgtfy.com/?q=code+kata
  83. “We have a great tool in this language. We can kill it by making a mess. We can kill it by being arrogant. We can kill it by ignoring the enterprise.”
  84. “Be daring, be different, be impractical, be anything that will assert integrity of purpose and imaginative vision against the play-it-safers, the creatures of the commonplace, the slaves of the ordinary.” ImpracticalQuote
  85. Marcello Duarte I work here I contribute here I tweet here @_md
  86. Thank you !
  87. Questions or Comments? joind.in/8110 slidesha.re/13sYRzS looking for a new challenge? inviqa.com/careers

×