Building working software is hard. But it's so much harder to build software that is easy to change. Yet this is a prerequisite for being truly agile, and a key enabler of agility is simplicity. But what exactly does simplicity mean and why is it so hard to achieve? It looks like complexity creeps in as soon as you stop paying attention, and most of it is accidental. Luckily, there are practical ways to get to simplicity by following good design principles and choosing simpler tools.

1. simplicity 0.3
Osvaldas Grigas
o.grigas@gmail.com

2. complexity 0.3
Osvaldas Grigas
o.grigas@gmail.com

3. inspired by
Dan
North
Rich
Hickey
J.B.
Rainsberger
Michael
Feathers

4. Edsger Dijkstra
(1980)
Computing's central challenge,
"How not to make a mess of it",
has not been met.

5. agile

6. agile
continuous improvement
based on frequent feedback

7. iterative development

13. incremental development

20. DONE

21. embrace the transient nature
of your code

22. Russ Miles
Complexity is the silent killer of
delivering change at the right time.

23. simplicity is prerequisite for agility

24. what is simplicity ?

25. Nothing is more simple
than a single giant button
MacBook Wheel

26. what "simple" isn’t ...

27. what "simple" isn’t ...
familiar / convenient

28. what "simple" isn’t ...
familiar / convenient
small / concise

29. what "simple" isn’t ...
familiar / convenient
small / concise
beautiful / elegant

31. “Simplicity -- the art of maximizing the
amount of work not done -- is essential.”
from the agile principles

32. YAGNI
from the agile principles
“Simplicity -- the art of maximizing the
amount of work not done -- is essential.”

33. “Technical excellence and
good design enhances agility.”
from the agile principles

34. Martin Fowler
Design is there to enable you to
keep changing the software easily.

35. when it comes to design ...

36. COMPLEXITY SUCKS
SIMPLICITY RULES

37. COMPLEXITY SUCKS ...

38. COMPLEXITY SUCKS ...
… your brain power

39. COMPLEXITY SUCKS ...
… your brain power

40. Rich Hickey
Once your software is of a
certain size, complexity is gonna
dominate what you can do.

43. essential
complexity

44. essential
complexity
your code

45. essential
complexity
your codelibraries
frameworks

46. essential
complexity
language
runtime
your codelibraries
frameworks

47. accidental
complexity
essential
complexity

48. SIMPLICITY RULES ...

49. SIMPLICITY RULES ...
… are …

50. SIMPLICITY RULES ...
… are …
The 4 Rules of Simple Design

51. SIMPLICITY RULES ...
… are …
The 4 Rules of Simple Design
1) passes all tests

52. SIMPLICITY RULES ...
… are …
The 4 Rules of Simple Design
1) passes all tests
2) clear, expressive names

53. SIMPLICITY RULES ...
… are …
The 4 Rules of Simple Design
1) passes all tests
2) clear, expressive names
3) no duplication

54. SIMPLICITY RULES ...
… are …
The 4 Rules of Simple Design
1) passes all tests
2) clear, expressive names
3) no duplication
4) minimal

55. rule #4: minimal

56. the less code,
the better

57. code folding

58. code
generators

59. dependency
managers

60. stop typing.
think!

61. test-first
(TDD / BDD)

62. rule #3: no duplication

63. primitive obsession
duplication in behavior

64. data clump
duplication in structure

65. refactoring

66. rule #2: clear, expressive names

67. small, focused methods
reduce cyclomatic complexity

68. small, focused classes
single responsibility

69. AccountService
AccountManager
AccountHandler
AccountUtils
AccountHelper
AccountImpl
AccountData
AccountDTO
AccountInfo
AccountDetails
AccountObject
AbstractAccount
BaseAccount
CustomAccount
SimpleAccount

70. refactoring

71. rule #1: passes all tests

72. unit testing

73. testability & good design

74. testability & good design
(but not integration tests)

75. inheritance-based design

76. wget -qO- http://c2.com/ | tr -cs '[:alpha:]' 'n' | sort | uniq
composition

77. dependencies

78. auto-import

79. refactoring
tools

80. A
G
F
D
C
introduce indirection

81. A
B
E G
F
D
C
introduce indirection

82. A
B
E G
F
D
C
follow
the law of Demeter
introduce indirection

83. modularity

84. coupling

85. add an interface?

86. layered architectures

87. add remoting?
SOAP

88. enterprise grade decoupling?
ESB

89. enterprise grade decoupling?
ESB
assumptions
assumptions

90. interface segregation

91. tell, don’t ask
high cohesion

92. dependency inversion
role

93. anti-corruption layer
adapter
role

94. notify
Payment
Order
Auditor
Financial
Event
Listener
Mongo
Audit
Trail
log
Audit
Trail
Mongo
Audit
Records
insert

95. Payment
Order
Audit
DAO
Audit
DAO
Impl
insert

96. further decoupling
queue
publish subscribe

97. use cases
& business rules
framework
persistence
framework
web
DB
infrastructure
messaging
QUEUE
task
scheduler
WS

98. Domain
Logic
Framework
Framework

99. Domain
Logic
Domain
Logic
Framework
Framework
accidental
complexity
complexity
leak

100. @Entity
@Table(name = "orders", schema = "com"})
public class Order implements Serializable {
@Id
@GeneratedValue(strategy = SEQUENCE, generator = "order_seq")
@Column(name = "ID", unique = true, nullable = false)
private Integer id;
@Column(name = "NUMBER", nullable = false, length = 8)
private String number;
@ManyToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
@JoinTable(name = "order_items", catalog = "com",
joinColumns = {@JoinColumn(name = "ORDER_ID",
updatable = false, nullable = false)},
inverseJoinColumns = {@JoinColumn(name = "ITEM_ID",
updatable = false, nullable = false)})
private Set<Item> items = new HashSet<Item>();
}

101. the law of leaky abstractions

102. home-grown
frameworks

103. libraries

104. state
& side effects

105. values
& pure functions

106. functional style imperative style

107. functional style
expressions
imperative style
statements

108. functional style
expressions
immutable values
imperative style
statements
mutable state

109. functional style
expressions
immutable values
data transformations
imperative style
statements
mutable state
side effects

110. functional style
expressions
immutable values
data transformations
recursion &
polymorphism
imperative style
statements
mutable state
side effects
looping &
branching

111. stepping out of
comfort zone

112. Edsger Dijkstra
(1980)
Computing's central challenge,
"How not to make a mess of it",
has not been met.

113. I‘m
done