Uploaded byChristophe Addinquy
Easy to use correctly, hard to use incorrectly
The document discusses principles for designing user interfaces and coding practices that promote correct usage while minimizing errors. It emphasizes the importance of clarity in naming, abstraction levels, and safe design practices like avoiding excessive use of getters and setters. Additionally, it touches on the evaluation of processes and usability in software development, including user story specifications and acceptance criteria.
More Related Content
Similar to Easy to use correctly, hard to use incorrectly
![[2015/2016] Software development process](https://cdn.slidesharecdn.com/ss_thumbnails/03devprocess-151201102814-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
Easy to use correctly, hard to use incorrectly
- 1. Easy to usecorrectly, hard to use incorrectly Christophe Addinquy, Zenika
- 2. www.agiletour.org05/11/10 Looking for wiseexpert rules ? There are too many of them ! (Even if they are clever) I end up with only one Robert Martin Craig Larman Martin Fowler Ken BeckPragmatic Programmers
- 3. www.agiletour.org « Make yourinterfaces easy to use correctly and hard to use incorrectly » Scott Meyers You can leave now !
- 4. Coding practices Design Userinterfaces Requirements Processes ?
- 5. Easy to use correctlyhard to use incorrectly Easy to use correctly easy to use incorrectly Hard to use correctly easy to use incorrectly Hard to use correctly hard to use incorrectly
- 7. Are you ready? •1 principle (to rule them all) •5 themes •20 exercises •1 reflexion
- 8. It all startswith some code...
- 9. Exercice 1 1 -What are the problems ? 2 - Spot this example
- 10. Naming can makeit hard to use correctly Naming should reveal the intention
- 11. What about parametersorder ? Exercice 2
- 12.
- 13. Size matters ...or at least abstraction level ! 1 - Keep algorithm readable 2 - Keep concerns at the same abstraction level
- 14. Good habits toprevent mistakes
- 15. Safe tests àla Joel Spolsky Can’t type ‘=’ instead of ‘==’
- 16. What about the programminglanguage ?
- 17.
- 18. Case conventions «builtin» in Ceylon
- 19. Let’s talk aboutdesign !
- 20. Getters & setters(1/4) Exercice 4 Design by
- 21. Getters & setters(2/4) Ooops !!!
- 22. Getters & setters(3/4) : RAII
- 23. Getters & setters(4/4) • Getters / Setters are not abstractions • Setters don’t enforce consistency However... Some frameworks require them !
- 24.
- 25.
- 26.
- 27.
- 28. Is your Decoratorsafe ? (1/2) Caller Service Decorator 1 Decorator 2 Exercice 7
- 29. Is your Decoratorsafe ? (2/2)
- 30. One step further: high level design...
- 31.
- 32.
- 33. Example 1 :Vintage and funny... •Chiptune Exercice 9
- 34. Example 2 :is it what we call «serious game» ? •SH Marketing Exercice 10
- 35. Example 3 :Ticket selling & Zen •Capitaine Train Exercice 11
- 36. It also appliesto requirements user stories...
- 37. Specify a userstory As a conference organizer I want to sell a limited set of early bird tickets between T-3 months and T-2 months so that I secure early incomes without jeopardizing the potential revenue Exercice 12
- 38. Acceptance criteria Early birdticket are available if the Early bird period is running and if there is enough early bird tickets left Exercice 13
- 39. Acceptance tests Let’s writesome acceptance tests together ! Exercice 14
- 40. Processes can alsobe evaluated this way !
- 41. Processes to evaluate Taylorism UnifiedProcess Extreme Programming Scrum Lean Evaluate «usability», not quality
- 42. Taylorism (scientific management) •Workers needs is «safety» by means of Maslow’s hierarchy of needs • The work at hand is highly decomposable and is almost mechanic • The worker is «stupid» and try to work as slow as possible Teaching Control Feedback Assumptions Exercice 15
- 43.
- 44.
- 45.
- 46.
- 47. Next (and last)level
- 48. Can the advicebe applied to itself Easy to use correctly, hard to use incorrectly Exercice 20
- 49. Relationship to agile I’mnot sure about it... My guts feeling tell methere is one ! Let me know what you think !
- 50.