Successfully reported this slideshow.
Test-driven Design/Development
TDD <ul><li>First agile practice to become mainstream </li></ul><ul><li>Chrysler Comprehensive Compensation system </li></...
Lean - Dealing with Change <ul><ul><li>Planning </li></ul></ul><ul><ul><ul><li>Incremental </li></ul></ul></ul><ul><ul><ul...
Agile - Dealing with Change <ul><li>Plan driven vs Planning Driven </li></ul><ul><li>Revise the plan weekly </li></ul><ul>...
Lean Manufacturing <ul><li>View the problem as a Software Delivery System </li></ul><ul><ul><li>Programmers, testers, desi...
Lean: “The Goal”- Eliyahu Goldratt <ul><li>Alex run a manufacturing plant soon to be closed </li></ul><ul><li>He knows a c...
Lean Basics: The Goal <ul><li>Increase the throughput </li></ul><ul><li>Decrease operating expenses </li></ul><ul><li>Decr...
Lean: Throughput <ul><li>How much potential revenue the system can create </li></ul><ul><li>Emphasis in deliver real softw...
Lean: Operating expenses <ul><li>Computers </li></ul><ul><li>Electricity </li></ul><ul><li>Rent </li></ul><ul><li>Insuranc...
Lean:Inventory <ul><li>Grocery Store </li></ul><ul><ul><li>What is in the shelve </li></ul></ul><ul><ul><li>I bet I can se...
Inventory in Software? <ul><li>Unused Features: Building a feature nobody is using [no payments] </li></ul><ul><li>Unrelea...
Inventory & Machine Utilization <ul><li>Machine spits out parts at 100% utilization </li></ul><ul><ul><li>Only 25% ended u...
Inventory: Unnecessary Complexity <ul><li>Developer adds complexity in anticipation </li></ul><ul><ul><li>Developer will h...
Inventory: Unnecessary Complexity <ul><li>The more unnecessary complexity </li></ul><ul><ul><li>The more difficult to chan...
TDD’s goal is to reduce Inventory <ul><li>Keeping the cost of adding a feature as low as we can by keeping the design simp...
Lean Basics: The Goal <ul><li>Increase the throughput (RTF/month) </li></ul><ul><li>Decrease operating expenses, - precede...
YAGNI - Decrease Unneeded Complexity  <ul><li>Design only what I need to solve the problem I have now :-( </li></ul><ul><l...
YAGNI - Decrease Unneeded Complexity <ul><li>Design in a way that prevents attacks from any direction </li></ul><ul><li>Fo...
TDD Principles <ul><li>Design is simple if it </li></ul><ul><ul><li>passes the test </li></ul></ul><ul><ul><li>minimizes d...
TDD Principle: Reduce Duplication <ul><li>“ I’m doing the same thing in five places, I have to change all five of them [Pu...
TDD Principle: Fix Bad Names <ul><li>By naming accurately </li></ul><ul><li>It is easier to understand how the code works ...
TDD Principle: Maximize Clarity <ul><li>Fix bad names </li></ul><ul><ul><li>name variables after what they represent </li>...
TDD Principle: Fix Bad Names <ul><li>Smell: too long with connectors like: “and”, “then”, “but”. That block of code  </li>...
TDD Principles <ul><li>Design is simple if it </li></ul><ul><ul><li>minimizes duplication </li></ul></ul><ul><ul><li>maxim...
TDD: Recfatoring <ul><li>Improving the design of existing code [book] </li></ul><ul><li>Systematic approach to improve the...
Refactoring: Systematic Approach <ul><li>Work in very small steps </li></ul><ul><ul><li>steps are reversible </li></ul></u...
Traditional Design <ul><li>We design something that meets a large number of requirements at once [cascade] Done by archite...
Evolutionary Design <ul><li>The act of writing the code give us information wether the design works or not, without that i...
Evolutionary Design by TDD <ul><li>Test drives the design. </li></ul><ul><li>A test articulates a goal so I know when to s...
Evolutionary Design: TDD cycle <ul><li>Write a failing test  </li></ul><ul><ul><li>Articulates a goal: “I need a little pi...
Evolutionary Design: TDD cycle <ul><li>A new intellectual challenge </li></ul><ul><ul><li>write it simple </li></ul></ul><...
Upcoming SlideShare
Loading in …5
×

Test-Driven Design - ¿Porqué?

734 views

Published on

Test-Driven Design (TDD) es una idea aparentemente simple: Escriba las pruebas para su código antes de escribir el código. Es "aparentemente simple" por que transforma el rol que testing juega en el proceso de desarrollo y cuestiona nuestros supuestos en la industria sobre el objetivo de testing. Testing ya no es solo acerca de evitar que los defectos lleguen al usuarios finales. Testing consiste en ayudar al equipo a entender las funcionalidad que los usuarios necesitan y hacer entrega de esas funcionalidad de forma confiable y productiva. Cuando TDD se sigue hasta sus últimas consecuencias, ocurren cambios radicales en la forma que desarrollamos software, la calidad de los sistemas que construimos mejora dramáticamente en términos de fiabilidad y flexibilidad en respuesta a nuevos requerimientos.
En esta charla:
• Los Administradores y Directores recibirán una justificación estratégica a nivel de negocios sobre TDD.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Test-Driven Design - ¿Porqué?

  1. 1. Test-driven Design/Development
  2. 2. TDD <ul><li>First agile practice to become mainstream </li></ul><ul><li>Chrysler Comprehensive Compensation system </li></ul><ul><ul><li>They needed something different </li></ul></ul><ul><ul><li>BUFP wasn’t working </li></ul></ul><ul><ul><li>How to deal with change instead of fighting it? </li></ul></ul>
  3. 3. Lean - Dealing with Change <ul><ul><li>Planning </li></ul></ul><ul><ul><ul><li>Incremental </li></ul></ul></ul><ul><ul><ul><li>frequent </li></ul></ul></ul><ul><ul><li>Small </li></ul></ul><ul><ul><ul><li>features </li></ul></ul></ul><ul><ul><ul><li>releases </li></ul></ul></ul>
  4. 4. Agile - Dealing with Change <ul><li>Plan driven vs Planning Driven </li></ul><ul><li>Revise the plan weekly </li></ul><ul><ul><li>reflect reality </li></ul></ul><ul><ul><li>make appropriate decisions </li></ul></ul>
  5. 5. Lean Manufacturing <ul><li>View the problem as a Software Delivery System </li></ul><ul><ul><li>Programmers, testers, designers, managers, BBAA. </li></ul></ul><ul><ul><li>Input: Feature request </li></ul></ul><ul><ul><li>Output: Let’s decide... </li></ul></ul>
  6. 6. Lean: “The Goal”- Eliyahu Goldratt <ul><li>Alex run a manufacturing plant soon to be closed </li></ul><ul><li>He knows a consultant (Jonah)!! </li></ul><ul><li>He learns a systems approach to manufacturing and its evaluation </li></ul><ul><li>This new system is counterintuitive: Not seeking 100% machine utilization </li></ul>
  7. 7. Lean Basics: The Goal <ul><li>Increase the throughput </li></ul><ul><li>Decrease operating expenses </li></ul><ul><li>Decrease inventory </li></ul>
  8. 8. Lean: Throughput <ul><li>How much potential revenue the system can create </li></ul><ul><li>Emphasis in deliver real software to real customers. It is only paid if it is used. </li></ul><ul><li>Running Tested Features per time unit </li></ul><ul><ul><li>RFT/month </li></ul></ul>
  9. 9. Lean: Operating expenses <ul><li>Computers </li></ul><ul><li>Electricity </li></ul><ul><li>Rent </li></ul><ul><li>Insurance </li></ul><ul><li>Wages ... </li></ul>
  10. 10. Lean:Inventory <ul><li>Grocery Store </li></ul><ul><ul><li>What is in the shelve </li></ul></ul><ul><ul><li>I bet I can sell it on time </li></ul></ul><ul><ul><li>It is not providing value (value = money) </li></ul></ul>
  11. 11. Inventory in Software? <ul><li>Unused Features: Building a feature nobody is using [no payments] </li></ul><ul><li>Unreleased features in source control </li></ul><ul><li>Unnecessary complexity: </li></ul><ul><ul><li>A developer adds complexity in anticipation of a future feature </li></ul></ul>
  12. 12. Inventory & Machine Utilization <ul><li>Machine spits out parts at 100% utilization </li></ul><ul><ul><li>Only 25% ended up ordered </li></ul></ul><ul><ul><li>8 hour shift: 200 sold and 600 stacking up on the floor </li></ul></ul><ul><ul><li>Walk around parts, new warehouse! </li></ul></ul><ul><ul><li>Operating expenses increased! Don’t use it at 100% </li></ul></ul>
  13. 13. Inventory: Unnecessary Complexity <ul><li>Developer adds complexity in anticipation </li></ul><ul><ul><li>Developer will have to walk around these parts from now on [we have spoiled customers!!] </li></ul></ul><ul><ul><li>Developers are slowed down </li></ul></ul><ul><ul><ul><li>More complexity </li></ul></ul></ul><ul><ul><ul><li>Probably adding duplication </li></ul></ul></ul>
  14. 14. Inventory: Unnecessary Complexity <ul><li>The more unnecessary complexity </li></ul><ul><ul><li>The more difficult to change </li></ul></ul><ul><ul><li>The harder to maintain </li></ul></ul><ul><ul><li>Marginal costs of features goes up </li></ul></ul><ul><li>The harder to maintain a system </li></ul><ul><ul><li>The more expensive the feature </li></ul></ul>
  15. 15. TDD’s goal is to reduce Inventory <ul><li>Keeping the cost of adding a feature as low as we can by keeping the design simple </li></ul>
  16. 16. Lean Basics: The Goal <ul><li>Increase the throughput (RTF/month) </li></ul><ul><li>Decrease operating expenses, - precedence </li></ul><ul><li>Decrease inventory </li></ul><ul><ul><li>Reduce unnecessary complexity </li></ul></ul><ul><ul><li>Reduce unused features </li></ul></ul><ul><ul><li>Reduce unreleased features </li></ul></ul>
  17. 17. YAGNI - Decrease Unneeded Complexity <ul><li>Design only what I need to solve the problem I have now :-( </li></ul><ul><li>I design what I need now in such a way that is ready for any change :-) </li></ul><ul><li>Example: Personal defense failure </li></ul>
  18. 18. YAGNI - Decrease Unneeded Complexity <ul><li>Design in a way that prevents attacks from any direction </li></ul><ul><li>Follow few principles to keep the design simple so the cost of implementing any new feature is reasonably low </li></ul><ul><li>Example: Personal defense Principles </li></ul>
  19. 19. TDD Principles <ul><li>Design is simple if it </li></ul><ul><ul><li>passes the test </li></ul></ul><ul><ul><li>minimizes duplication </li></ul></ul><ul><ul><li>maximizes clarity </li></ul></ul><ul><ul><li>is small </li></ul></ul><ul><li>1. is assumed and 4. is a by-product </li></ul>
  20. 20. TDD Principle: Reduce Duplication <ul><li>“ I’m doing the same thing in five places, I have to change all five of them [Put rationalized justification] so I copied and pasted in four places, I forgot the fifth one” ⇒ bug </li></ul>
  21. 21. TDD Principle: Fix Bad Names <ul><li>By naming accurately </li></ul><ul><li>It is easier to understand how the code works </li></ul><ul><li>we may detect smells (name too weird?) </li></ul>
  22. 22. TDD Principle: Maximize Clarity <ul><li>Fix bad names </li></ul><ul><ul><li>name variables after what they represent </li></ul></ul><ul><ul><li>name methods after what they do </li></ul></ul><ul><ul><li>name classes what they are </li></ul></ul><ul><ul><li>name interfaces after what the role they play </li></ul></ul>
  23. 23. TDD Principle: Fix Bad Names <ul><li>Smell: too long with connectors like: “and”, “then”, “but”. That block of code </li></ul><ul><ul><li>is doing too much work </li></ul></ul><ul><ul><li>too many responsibilities </li></ul></ul><ul><ul><li>it duplicates responsibilities with another part of the system </li></ul></ul>
  24. 24. TDD Principles <ul><li>Design is simple if it </li></ul><ul><ul><li>minimizes duplication </li></ul></ul><ul><ul><li>maximizes clarity </li></ul></ul><ul><li>Claim: IF WE FOLLOW THESE PRINCIPLES WE REDUCE INVENTORY CREATED BY UNNECESSARY COMPLEXITY </li></ul>
  25. 25. TDD: Recfatoring <ul><li>Improving the design of existing code [book] </li></ul><ul><li>Systematic approach to improve the design without throwing a piece a way while rewritten it. </li></ul>
  26. 26. Refactoring: Systematic Approach <ul><li>Work in very small steps </li></ul><ul><ul><li>steps are reversible </li></ul></ul><ul><ul><li>I can stop if I want to </li></ul></ul><ul><ul><li>Keep the code working at every step </li></ul></ul><ul><ul><li>I have tests (behavioral spec) that tells me if a structural change breaks behavior </li></ul></ul>
  27. 27. Traditional Design <ul><li>We design something that meets a large number of requirements at once [cascade] Done by architects, handed off to developers </li></ul><ul><li>Caveat with high level design ideas: </li></ul><ul><ul><li>high levels ideas right most of the time </li></ul></ul><ul><ul><li>low level detail wrong most of the time </li></ul></ul>
  28. 28. Evolutionary Design <ul><li>The act of writing the code give us information wether the design works or not, without that information, we can’t design effectively. </li></ul><ul><li>Write code in a way that allows us to start with the low level detail and use some basic principles to make sure the high level ideal designs ideas work well </li></ul>
  29. 29. Evolutionary Design by TDD <ul><li>Test drives the design. </li></ul><ul><li>A test articulates a goal so I know when to stop </li></ul>
  30. 30. Evolutionary Design: TDD cycle <ul><li>Write a failing test </li></ul><ul><ul><li>Articulates a goal: “I need a little piece of software to does this” </li></ul></ul><ul><li>Make the test pass: </li></ul><ul><ul><li>Don’t write any production code if there isn’t a failing test that requires it [no inventory]. Failing test evidence of need </li></ul></ul>
  31. 31. Evolutionary Design: TDD cycle <ul><li>A new intellectual challenge </li></ul><ul><ul><li>write it simple </li></ul></ul><ul><ul><li>articulate the goal with less code </li></ul></ul><ul><ul><li>pass the test with less code </li></ul></ul><ul><ul><li>remove duplication, make it clearer </li></ul></ul>

×