We are all seeking for good advices, recipes and rules of thumbs to make our designs better, our requirements strong and accurate, our user interfaces outstanding and more and more... But there are as many set of rules our advices as there are gurus. And as smart as they are, their rules are only good advices, not final weapons usable in each and every situation. It's because there is no final weapon. Human mind can't be replaced and will not be. Then I crossed Scott Meyer advice. Amazingly it help me to challenge my ideas in programming, design, user interfaces, even in the way I can mitigate user stories or make iteration priorities ! Agile teams are targeting excellence. Code, design and functionalities are not here forever : they are reused, refactored, improved or changed. We want functionalities delighting our customers and be handled without questions. This sessions will help you make a step in this direction by illustrating what it means to build things easy to use correctly and hard to use incorrectly. We will see that successively with code, design structures, requirements, user interfaces and even agile practices ! You will be invited to judge the examples against Scott Meyer's principle and sometime to improve them and make them better.

1. Easy to use correctly, hard to use incorrectly
Christophe Addinquy, Zenika

2. www.agiletour.org05/11/10
Looking for wise expert 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 your interfaces easy to
use correctly and hard to use
incorrectly »
Scott Meyers
You can leave now !

4. Coding practices Design
User interfaces Requirements
Processes
?

5. Easy to use
correctly hard 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 starts with some
code...

9. Exercice 1
1 - What are the problems ?
2 - Spot this example

10. Naming can make it hard to use correctly
Naming should reveal the intention

11. What about parameters order ?
Exercice 2

12. Exercice 3

13. Size matters ... or at least abstraction level !
1 - Keep algorithm readable
2 - Keep concerns at the same abstraction level

14. Good habits to prevent mistakes

15. Safe tests à la Joel Spolsky
Can’t type ‘=’ instead of ‘==’

16. What about the
programming language ?

17. Type system

18. Case conventions «built in» in Ceylon

19. Let’s talk about design !

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. Protocole usage (1/4)

25. Protocole usage (2/4)
Exercice 5

26. Protocole usage (3/4)
Exercice 6

27. Protocole usage (4/4)

28. Is your Decorator safe ? (1/2)
Caller Service
Decorator
1
Decorator
2
Exercice 7

29. Is your Decorator safe ? (2/2)

30. One step further : high
level design...

31. Convention over configuration
Exercice 8

32. What about user
interfaces ?

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 applies to
requirements user
stories...

37. Specify a user story
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 bird ticket 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 write some acceptance
tests together !
Exercice 14

40. Processes can also be
evaluated this way !

41. Processes to evaluate
Taylorism
Unified Process
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. Unified process
Exercice 16

44. Extreme Programming
Exercice 17

45. Scrum
Exercice 18

46. Lean
Exercice 19

47. Next (and last) level

48. Can the advice be applied to itself
Easy to use
correctly, hard to
use incorrectly
Exercice 20

49. Relationship to agile
I’m not sure about it...
My guts feeling tell methere is one !
Let me know what you think !

50. Thank you !
christophe.addinquy@zenika.com
@addinquy
http://freethinker.addinq.uy
addinquy
addinquy
addinquy
addinquy
addinquy