The document discusses the principles of simple design for software development. It outlines four rules: 1) all tests must pass, 2) no duplicated code, 3) code is self-explanatory, and 4) no superfluous parts. The document argues that simple design focuses on removing duplication and fixing poorly named code, as this helps the appropriate structure and responsibilities emerge in the design. Choosing good names that are pronounceable, intention-revealing, and use a ubiquitous language is also discussed.

1. The First 100 Hours:
Simple Design
Jason Cheong-Kee-You
@jpcky www.mightyjupiter.com
Alistair McKinnell
@amckinnell www.valuablecode.com

2. The First 100 Hours

3. The First 100 Hours
1. Learning
2. Test-Driven Development
3. Design

4. Pair Programming

5. 44 A Rhythm for Success: The
TDD Cycle
R ed
Gre
tor
en
ac
R ef
Prepared exclusively for Alistair McKinnell Copyright ©2011 Pragmatic Programmers

7. Where DoYou Stand?

8. Simple Design

9. Simple Design
1. All tests must pass
2. No code is duplicated
3. Code is self-explanatory
4. No superfluous parts exist

10. Exercise

11. Exercise
Why are the four rules of
simple design important?

13. Simple Design
1. All tests must pass
2. No code is duplicated
3. Code is self-explanatory
4. No superfluous parts exist

14. Simple Design
1. Passes its tests
2. No code is duplicated
3. Code is self-explanatory
4. No superfluous parts exist

15. Simple Design
1. Passes its tests
2. Minimizes duplication
3. Code is self-explanatory
4. No superfluous parts exist

16. Simple Design
1. Passes its tests
2. Minimizes duplication
3. Maximizes clarity
4. No superfluous parts exist

17. Simple Design
1. Passes its tests
2. Minimizes duplication
3. Maximizes clarity
4. Has fewer elements

18. Simple Design
1. Passes its tests (given TDD)
2. Minimizes duplication
3. Maximizes clarity
4. Has fewer elements

19. Simple Design
1. Passes its tests (given TDD)
2. Minimizes duplication
3. Maximizes clarity (fix names)
4. Has fewer elements

20. Simple Design
1. Passes its tests (given TDD)
2. Minimizes duplication
3. Maximizes clarity (fix names)
4. Has fewer elements

21. That leaves me with two key elements
of simple design: remove duplication and
fix bad names.
When I remove duplication, I tend to see
an appropriate structure emerge, and when
I fix bad names, I tend to see responsibilities
slide into appropriate parts of the design.
J. B. Rainsberger

22. Simple Design
• Remove duplication
• Fix bad names

23. Exercise

24. Exercise
How to choose good names?
Build a checklist

25. Choosing Good Names

26. Choosing Good Names
Pronounceable Names
Avoid Encodings

27. Choosing Good Names
Intention-Revealing Name
Role-Suggesting Name

28. Choosing Good Names
Ubiquitous Language

29. Simple Design
1. All tests must pass
2. No code is duplicated
3. Code is self-explanatory
4. No superfluous parts exist

30. Simple Design
• Remove duplication
• Fix bad names

32. “The prime directive that was
unanimously agree upon by all
present was that in the next
tens years Agile leaders must
Demand Technical Excellence”
Jeff Sutherland

33. “Failure to do that means
you are not an Agile leader”
Jeff Sutherland

34. Photo Credits
http://www.flickr.com/photos/54087404@N00/4638056301/
http://www.flickr.com/photos/49016492@N08/4534101229/
http://www.flickr.com/photos/27558040@N00/4151899795/
http://www.flickr.com/photos/21561428@N03/5520629205/
http://www.flickr.com/photos/flatcat/3555774083/