Presentation at Agile 2012 Experience and research shows that developers spend as much as 70% of their time reading and understanding code. In this workshop you will learn how the rules of Simple Design help to reduce this percentage so you spend more time creating valuable code. This will be a highly collaborative workshop where you share your insights and learn from others. You’ll get to the heart of Simple Design by reviewing code - both beautiful and ugly. You’ll get to practice by improving the readability and understandability of real code. You’ll leave this workshop ready to apply Simple Design to improve your own code.

1. Simple Design Applied
Spend more time creating
valuable code
Alistair McKinnell Declan Whelan
@mckinnell @dwhelan

2. Exercise

3. What is Simple Design?
On an index card write up to
three facts on an index card.
Be ready to share with
your table.

4. What is Simple Design?
At your table gather the facts
and count how many distinct
facts you came up with.

5. Introductions
?

6. www.XProgramming.com

8. Exercise

9. Simple Design
At your table order the
rules of simple design in
priority order.

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

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

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

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

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

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

17. Simple Design
1. Passes its tests (given TDD)
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 (fix names)
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. 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

21. Simple Design
• Remove duplication
• Fix bad names

22. Simple Design
(for today)
• Fix bad names
❤ Choosing good names
• Remove duplication
❤ Commonality & Variability

23. Exercise

24. Stroop Effect
Green Red Blue
Purple Blue Purple
Green Red Blue
Purple Blue Purple
Blue Purple Red
Green Purple Green

25. Meaning:
Colour:
black
yellow

26. Meaning:
Colour:
blue
black

27. black
yellow

28. yellow
red

29. red
yellow

30. red
yellow

31. blue
blue

32. yellow
blue

33. red
red

34. blue
red

35. yellow
yellow

36. red
yellow

37. red
yellow

38. blue
black

39. yellow
black

40. black
blue

41. red
black

42. The
End

43. Exercise

44. CComBstr sVal $.getJSON() int result
Rx rx applyMeasureConstraintToEnableSortingByMeasure() float hp
applyPhq9DateRangeConstraint() public void run() Date genymdhms
m_name Label label IShapeFactory
Customer int i RollOverPerformanceIndicatorsToNextMonthTask
CustomerManager LPSTR lpCmdLine int daysSinceModification
boolean fNewPage UpdatePerfIndValueDecCountCmd DepressionSelfManagementCalculator
Tutorial02
PerfIndValueDecCountForMatchingIvpCmd PulseRenderer IndexCardPageLayout sut

45. CComBstr sVal $.getJSON() int result
Rx rx applyMeasureConstraintToEnableSortingByMeasure() float hp
applyPhq9DateRangeConstraint() public void run() Date genymdhms
m_name Label label IShapeFactory
Customer int i RollOverPerformanceIndicatorsToNextMonthTask
CustomerManager LPSTR lpCmdLine int daysSinceModification
boolean fNewPage UpdatePerfIndValueDecCountCmd DepressionSelfManagementCalculator
Tutorial02
PerfIndValueDecCountForMatchingIvpCmd PulseRenderer IndexCardPageLayout sut

46. Find a partner and each of you:
1. select a name you thought was good
2. explain why to your partner
3. select a name you thought was bad
4. explain why to your partner
CComBstr sVal $.getJSON() int result
Rx rx applyMeasureConstraintToEnableSortingByMeasure() float hp
applyPhq9DateRangeConstraint() public void run() Date genymdhms
m_name Label label IShapeFactory
Customer int i RollOverPerformanceIndicatorsToNextMonthTask
CustomerManager LPSTR lpCmdLine int daysSinceModification
boolean fNewPage UpdatePerfIndValueDecCountCmd DepressionSelfManagementCalculator
PerfIndValueDecCountForMatchingIvpCmd PulseRenderer IndexCardPageLayout sut

47. Choosing Good Names

48. Choosing Good Names
Use the telephone test for readability.
If someone could understand your
code when read aloud over the
telephone, it's clear enough.
If not, then it needs rewriting.

49. Telephone Test
Goal Donor vs Gold Owner
Date genymdhms

50. Choosing Good Names
Splitters can be lumped more easily
than lumpers can be split.
It is easier to combine two concepts
that it is to separate them.

51. Splitting a Lumper
Customer Address

52. Splitting a Lumper
Customer Address
Billing Address Mailing Address Service Address

53. Lumping a Splitter
Billing Address Mailing Address Service Address

54. Lumping a Splitter
Billing Address Mailing Address Service Address
Customer Address

55. Choosing Good Names
Pronounceable Names
Avoid Encodings

56. Pronounceable Names
UpdatePerfIndValueDecCountCmd

57. Pronounceable Names
UpdatePerfIndValueDecCountCmd
DecrementAggregateCommand

58. Pronounceable Names
Date genymdhms

59. Pronounceable Names
Date genymdhms
Date generatedTimestamp

60. Avoid Encodings
LPSTR lpCmdLine
LPSTR commandLine
m_name
name

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

62. Intention-Revealing Name
applyMeasureConstraintTo
EnableSortingByMeasure()

63. Intention-Revealing Name
applyMeasureConstraintTo
EnableSortingByMeasure()
applyMeasureConstraint()

64. Role-Suggesting Name
int result
IndexCardPageLayout sut

65. Choosing Good Names
Ubiquitous Language

66. Ubiquitous Language
CComBstr sVal

67. Ubiquitous Language
CComBstr sVal
CComBstr calibrationToolName

68. Ubiquitous Language
Rx rx

69. Ubiquitous Language
Rx rx
Rx refillable

70. Ubiquitous Language
applyPhq9DateRangeConstraint()
The PHQ-9 is the nine item depression scale of
the Patient Health Questionnaire.
The PHQ-9 is a powerful tool for assisting primary
care clinicians in diagnosing depression as well as
selecting and monitoring treatment.

71. Pragmatic
Programmers Agile in a Flash
Speed-Learning Agile
Software Development
Agile Cards for
Agile Teams
Jeff Langr and
Tim Ottinger
edited by Susannah Pfalzer
Prepared exclusively for Alistair McKinnell Copyright ©2011 Pragmatic Programmers

72. 43 Really Meaningful Names
® Are accurate
® Are purposeful
® Are pronounceable
® Begin well
® Are simple
® Depend on context
® Match name length to scope
Prepared exclusively for Alistair McKinnell Copyright ©2011 Pragmatic Programmers

73. Choosing Good Names
•Locate one
Naming'Guidelines
System'of'Names
S1# # Name#pass#the#“telephone”#test.
S2# # There#is#a#clean#name#for#each#concept.#Remember:#later#on#it’s#easier#to#lump#
guideline that if
things#together#than#to#split#them#apart.
S3# # Name#is#from#the#problem#or#solu?on#domain#and#support#ubiquitous#language#for#
the#team
General
applied would have
G1## Name#is#pronounceable.
G2## Name#avoids#encodings#and#member#prefixes.
G3## Name#suggest#why#it#exists.
G4## Name#suggest#how#it#should#be#used.
the biggest impact
G5## Name#suggest#what#it#does.
G6## Name#is#easily#searchable#in#the#code#base.
Classes
C1# If#this#is#an#important#base#class#its#class#name#should#be#a#simple#single#word.
C2#
C3#
If#this#is#a#subclass#its#class#name#suggests#how#it#differs#from#its#superclass.
The#class#name#is#a#noun#or#a#noun#phrase.
on your code
•Find a partner
Methods
M1# The#method#name#suggests#why#it#would#be#called.
M2# The#method#is#name#a#verb#or#a#verb#phrase.
Variables/Fields/Arguments
•Discuss
V1# Its#name#indicate#the#role#it's#playing.
V2# The#length#of#the#name#reflect#its#scope.
Alistair McKinnell @amckinnell Declan Whelan @dwhelan
Naming Guidelines v1.0 August 2012 ! 1/1

74. Choosing Good Names
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}
Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, pages 18-19

75. Choosing Good Names
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}
public List<int[]> getFlaggedCells() {
List<int[]> flaggedCells = new ArrayList<int[]>();
for (int[] cell : gameBoard)
if (cell[STATUS_VALUE] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}
Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, pages 18-19

76. Choosing Good Names
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}
public List<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
if (cell.isFlagged())
flaggedCells.add(cell);
return flaggedCells;
}
Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, pages 18-19

77. Choosing Good Names
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}
public List<Cell> getFlaggedCells() {
List<Cell> result = new ArrayList<Cell>();
for (Cell cell : gameBoard)
if (cell.isFlagged())
result.add(cell);
return result;
}
Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, pages 18-19

78. Choosing Good Names
int s = 0;
for (int j=0; j<34; j++) {
s += (t[j]*4)/5;
}
const int EFFECTIVE_DAYS_PER_WEEK = 4;
int realDaysPerIdealDay = 4;
const int WORKING_DAYS_PER_WEEK = 5;
const int WORK_DAYS_PER_WEEK = 5;
int sum = 0;
int effectiveTotalEstimate = 0;
for (int j=0; j < NUMBER_OF_TASKS; j++) {
for (int j=0; j < NUMBER_OF_TASKS; j++) {realDaysPerIdealDay;
int realTaskDays = taskEstimate[j] *
int effectiveTaskEstimate =
int realTaskWeeks = (realdays / WORK_DAYS_PER_WEEK);
taskEstimate[j] * EFFECTIVE_DAYS_PER_WEEK / WORKING_DAYS_PER_WEEK;
sum += realTaskWeeks;
effectiveTotalEstimate += effectiveTaskEstimate;
}
}
Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, page 23

79. What’s In A Name?
Moonbeam
Zappa

81. All tests must pass No code is duplicated
Code is self-explanatory No superfluous parts exist

82. No code is duplicated

83. Exercise

84. How do you handle
duplicate code
in your codebase?

86. Avoiding Duplicate Code
DRY: Don’t Repeat Yourself
Every piece of knowledge must have
a single, unambiguous, authoritative
representation within a system.

87. Avoiding Duplicate Code
Once and Only Once
Data, structure, or logic should exist
in only one place in the system.

88. Avoiding Duplicate Code
Test-Driven Development
1. Write new code only if an
automated test has failed.
2. Eliminate duplication.

89. Avoiding Duplicate Code
Single Choice Principle
Whenever a software system must
support a set of alternatives, one
and only one module in the system
should know their exhaustive list.

90. Avoiding Duplicate Code
Duplication may be the
root of all evil in software.

92. Commonality and Variability

93. Copy & Paste

94. function something() {
}

95. function something() {
}
function something() {
}

96. function something() {
}
function somethingElse() {
}

97. function something() {
}
function somethingElse() {
}

98. Duplicate Code
Copy & Paste
Edit the Copy
☞ Duplicate Code

99. Duplicate Code
Avoid duplication by expressing
commonality and variability
explicitly.

100. function something() {
}
function somethingElse() {
}

101. Duplicate Code:
Select Options

102. Can you spot the
commonality and variation?
Can you spot the duplicate code?
How would you make the
commonality and variation explicit?

104. public static List<SelectOption> createEndMonthList(Date expiryDate) {
int selectedMonth = getDateMonth(expiryDate);
SelectOptionsSource months = new SelectOptionsSource(1, 12, selectedMonth);
SelectOptions monthOptions = new SelectOptions(months);
return monthOptions.create();
}
public static List<SelectOption> createEndDaysList() {
int selectedDay = getDateDay(getCurrentDatePlus14Days());
SelectOptionsSource days = new SelectOptionsSource(1, 31, selectedDay);
SelectOptions dayOptions = new SelectOptions(days);
return dayOptions.create();
}
public static List<SelectOption> createEndYearList() {
int selectedYear = getDateYear(getCurrentDatePlus14Days());
SelectOptionsSource years = new SelectOptionsSource(1985, 1985 + 30, selectedYear);
SelectOptions yearOptions = new SelectOptions(years);
return yearOptions.create();
}

105. public static List<SelectOption> createEndMonthList(Date expiryDate) {
int selectedMonth = getDateMonth(expiryDate);
SelectOptionsSource months = new SelectOptionsSource(1, 12, selectedMonth);
SelectOptions monthOptions = new SelectOptions(months);
return monthOptions.create();
}
public static List<SelectOption> createEndDaysList() {
int selectedDay = getDateDay(getCurrentDatePlus14Days());
SelectOptionsSource days = new SelectOptionsSource(1, 31, selectedDay);
SelectOptions dayOptions = new SelectOptions(days);
return dayOptions.create();
}
public static List<SelectOption> createEndYearList() {
int selectedYear = getDateYear(getCurrentDatePlus14Days());
SelectOptionsSource years = new SelectOptionsSource(1985, 1985 + 30, selectedYear);
SelectOptions yearOptions = new SelectOptions(years);
return yearOptions.create();
}

106. public static List<SelectOption> createEndMonthList(Date expiryDate) {
int selectedMonth = getDateMonth(expiryDate);
SelectOptionsSource months = new SelectOptionsSource(1, 12, selectedMonth);
SelectOptions monthOptions = new SelectOptions(months);
return monthOptions.create();
}
public static List<SelectOption> createEndDaysList() {
int selectedDay = getDateDay(getCurrentDatePlus14Days());
SelectOptionsSource days = new SelectOptionsSource(1, 31, selectedDay);
SelectOptions dayOptions = new SelectOptions(days);
return dayOptions.create();
}
public static List<SelectOption> createEndYearList() {
int selectedYear = getDateYear(getCurrentDatePlus14Days());
SelectOptionsSource years = new SelectOptionsSource(1985, 1985 + 30, selectedYear);
SelectOptions yearOptions = new SelectOptions(years);
return yearOptions.create();
}

107. Select Options
SelectOptions SelectOptionsSource
create() getFirst()
getLast()
isSelected()
Commonality Variability Resolution
Encapsulate
Behaviour Collaborator
Collection

108. Select Options
SelectOptions SelectOptionsSource
create() getFirst()
getLast()
isSelected()
Commonality Variability Resolution
Data Structure Value of State Simple Java Type

110. Select Options
SelectOptions SelectOptionsSource
create() getFirst()
getLast()
isSelected()
Encapsulate
Collection

111. Select Options
SelectOptions SelectOptionsSource
create() getFirst()
getLast()
isSelected()
Parameter
Object

112. Duplicate Code:
Compound Result Handler

113. Can you spot the
commonality and variation?
Can you spot the duplicate code?
How would you make the
commonality and variation explicit?

114. if ( ... ) {
} else {
}

115. Compound Result Handler
CompoundResultHandler CompoundResultClassifier
isNegative()
isPositive()
AbstractCompoundResultClassifier
toNumber()
QueensCompoundResultClassifier StandardCompoundResultClassifier
isNegative() isNegative()
isPositive() isPositive()

116. Compound Result Handler
CompoundResultHandler CompoundResultClassifier
isNegative()
isPositive()
AbstractCompoundResultClassifier
toNumber()
QueensCompoundResultClassifier StandardCompoundResultClassifier
isNegative() isNegative()
isPositive() isPositive()

117. Compound Result Handler
CompoundResultHandler CompoundResultClassifier
isNegative()
isPositive()
AbstractCompoundResultClassifier
toNumber()
QueensCompoundResultClassifier StandardCompoundResultClassifier
isNegative() isNegative()
isPositive() isPositive()
Commonality Variability Resolution
Inheritance
Behaviour Implementation
(Object-Oriented)

118. Compound Result Handler
CompoundResultHandler CompoundResultClassifier
isNegative()
isPositive()
AbstractCompoundResultClassifier
toNumber()
QueensCompoundResultClassifier StandardCompoundResultClassifier
isNegative() isNegative()
isPositive() isPositive()
Commonality Variability Resolution
Inheritance
Behaviour Implementation
(Object-Oriented)

119. Compound Result Handler
CompoundResultHandler CompoundResultClassifier
isNegative()
isPositive()
AbstractCompoundResultClassifier
toNumber()
QueensCompoundResultClassifier StandardCompoundResultClassifier
isNegative() isNegative()
isPositive() isPositive()
Commonality Variability Resolution
Implementation None Base Class

120. Compound Result Handler
CompoundResultHandler CompoundResultClassifier
isNegative()
isPositive()
AbstractCompoundResultClassifier
toNumber()
QueensCompoundResultClassifier StandardCompoundResultClassifier
isNegative() isNegative()
isPositive() isPositive()
Commonality Variability Resolution
Implementation None Base Class

121. Compound Result Handler
public static CompoundResultClassifier createCompoundResultClassifier(
Patient sourcePatient) {
return isRegisteredAtQueens(sourcePatient) ? QUEENS : STANDARD;
}
private static boolean isRegisteredAtQueens(Patient sourcePatient) {
return sourcePatient.getDataWarehouse().equals(DataWarehouseTag.QHN);
}
Factory

123. Avoiding Duplicate Code

124. Commonality and Variability

125. Duplicate Code
Copy & Paste
Edit the Copy
☞ Duplicate Code

126. Duplicate Code
Avoid duplication by expressing
commonality and variability
explicitly.

128. All tests must pass No code is duplicated
Code is self-explanatory No superfluous parts exist

129. 0 10 20 30 40 50 60 70 80

130. 0 10 20 30 40 50 60 70 80

131. “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

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

133. Personal Action Plan

134. Reading
The Elements of Programming Style
Kernighan and Plauger
Prefactoring
Extreme Abstraction Extreme Separation Extreme Readability
Ken Pugh
Pragmatic
Programmers Agile in a Flash
Speed-Learning Agile
Software Development
Agile in a Flash
Agile Cards for
Agile Teams Speed-Learning Agile Development
Jeff Langr and
Tim Ottinger
edited by Susannah Pfalzer
Jeff Langr and Tim Ottinger
Prepared exclusively for Alistair McKinnell

135. Reading
Clean Code
A Handbook of Agile Software Craftsmanship
Robert C. Martin
Domain Driven Design
Tackling Complexity in the Heart of Software
Eric Evans
Implementation Patterns
Kent Beck

136. Reading
The Pragmatic Programmer: From Journeyman to Master
Andrew Hunt and Dave Thomas
Extreme Programming Explained: Embrace Change
Kent Beck and Cynthia Andres
Test Driven Development: By Example
Kent Beck
Object-Oriented Software Construction
Bertrand Meyer

137. Reading
Design Patterns: Elements of Reusable
Object-Oriented Software Erich Gamma,
Richard Helm, Ralph Johnson, and John Vlissides
Multi-Paradigm Design for C++
James O. Coplien
Lean Architecture: for Agile Software Development
James O. Coplien and Gertrud Bjørnvig

138. Photo Credits
http://www.flickr.com/photos/27558040@N00/4151899795/
http://www.flickr.com/photos/popilop/331357312/
http://www.flickr.com/photos/arlette/3260468/
http://www.flickr.com/photos/36829973@N04/3546657245/
http://www.flickr.com/photos/40838054@N00/7261734660/