https://www.youtube.com/watch?v=qO73yObPYac

2. Yin-Yangs
of Software Development
Naveen Muguda

3. dual
• consisting of two parts
• related to another by the interchange of parts or properties

4. 0 x-x

5. (x, y)(-x, y)
(x, -y)(-x, -y)

6. Personality : Character

7. Effort: Knowledge

8. ನಿಮ್ಮೆಲ್ಲರಿಗೂ ಶುಭ ೂೋದಯ

9. On demand learning : learning apriori

10. • Sort an array where each element is 0 or 1
• Sort an array where each element is in [0, k)
• Sort an array of integers

11. S-Program : E-Program

12. Two poses

13. Simple : Easy

16. • “In fact, zero -- as a number or a concept -- is a shockingly new idea in
western civilization. For nearly everyone in Europe, such a thing was
unthinkable until the 14th century at the earliest. That's nearly 1,000
years after zero's invention.”

17. Need : Ease

20. public interface UserRepository {
public void add(User user);
public void addAll( Collection<User> users);
public void remove(User user);
public void removeAll(Collection<User> users);
...
}

22. public interface WorkManager {
void doAtomic(CheckedConsumer<RepositoryContext> consumer) throws TransactionException;
<T> T unit(CheckedFunction<RepositoryContext, T> mapper) throws TransactionException;
}

23. public List<User> getAllUsers() throws InternalException {
return _userRepoMapper.wrap(UserRepoHelper::getAll, "Error getting CS users");
}

24. public long createRole(Role role) throws InternalException {
try {
return _workManager.unit(repositoryContext -> create(role, repositoryContext));
} catch (TransactionException e) {
throw new InternalException("Unable to create role ", e);
}
}

26. No discipline, no motivation
No motivation, discipline
motivation, no discipline motivation, discipline

27. Focalism
• Over-simplified

28. Binary Thinking : Yin-Yang

29. Yin : Yang
is a concept of dualism,
describing how seemingly opposite or contrary forces may actually be
complementary, interconnected, and interdependent in the natural
world.

30. Perception is Reality
• It isn’t.

31. Run : Recovery

32. Brake : Accelerator pedal

35. • Balance
• Cycle
• Interdependencies
• equilibrium

36. Play : work
All work and no play makes Jack a dull boy,
All play and no work makes Jack a mere toy.

37. Theory : Practice
Theory Without Practice Is Empty;
Practice Without Theory Is Blind

38. Obvious
• 0 - 1
• If - else
• Free-malloc
• Request-response
• Publish-subscribe
• Scatter gather
• Lock-unlock

39. Org : Architecture
• Conway’s law
• Self organizing teams
• Loosely coupled organizations

40. public static int ? (int i) {
i = i - ((i >>> 1) & 0x55555555);
i = (i & 0x33333333) + ((i >>> 2) & 0x33333333);
i = (i + (i >>> 4)) & 0x0f0f0f0f;
i = i + (i >>> 8);
i = i + (i >>> 16);
return i & 0x3f;
}

41. Essence : Ceremony
• Compose method pattern
• Functional programming

42. Compose method pattern
void someMethod(){
//do some stuff
line 1
line 2
line 3
//calculate some other stuff
line 4
line 5
line 6
//do final stuff
line 7
line 8
line 9
}
void someMethod(){
doSomeStuff();
calculateSomeOtherStuff();
doFinalStuff();
}
void doSomeStuff(){
line 1
line 2
line 3
}
void calculateSomeOtherStuff(){
line 4
line 5
line 6
}
void doFinalStuff(){
line 7
line 8
line 9
}

43. Secondary benefits
• part-methods become better tested
• part-methods and whole-methods are scrutinized more
• part-methods become use-able in multi-contexts
• part-methods are closed before the whole

44. Employee employee = Stream.of(empIds)
.map(employeeRepository::findById)
.filter(e -> e != null)
.filter(e -> e.getSalary() > 100000)
.findFirst()
.orElse(null);

45. • E-programs built on S-programs

46. Functional style
Function<Egg, BoiledEgg> f1 =
Function<Egg, PeeledEgg> f2 =
List<Egg> eggs =
eggs.stream
. map(f1)
.map(f2)
=>
peel(
boil(eggs.stream)
)
Function<Stream<Egg>, Stream<BoiledEgg>> boil = stream -> stream.map(f1)

47. public int fibonacci(int n) {
return Matcher.of(n)
.when(is(1), 0)
.when(is(2), 1)
.orElse(m -> fibonacci(m - 1) + fibonacci(m - 2)); }
public static int fibonacci(int n){
if(n == 1)
return 0;
else if (n == 2)
return 1;
else
return fibonacci(n - 1) + (n -2);
}
public int fibonacci(int n) {
return Matcher.of(n)
.when(is(1), 0)
.when(is(2), 1)
.orElse(m -> fibonacci(m - 1) + fibonacci(m - 2)); }
public static int fibonacci(int n){
if(n == 1)
return 0;
else if (n == 2)
return 1;
else
return fibonacci(n - 1) + (n -2);
}
funp

51. Design for Manufacturing : Design for Assembly

53. Run time efficiency : Development time efficiency

54. Design for Performance : Design for Evolution

55. Software design >>> System design

56. Ad hoc : Structured

57. Top : Down
• DDD
• BDD

58. Machine : Man
Machine Man
Local Global
Progress Goal
Detail Idea
Vast Memory Limited Memory
Reliable Error Prone

59. int month enum Month {
JANUARY, FEBRUARY, ….
public Month(int month) {
if(month < 1 || month > 12)
throw new IllegalArgumentException()
}
}

60. Concept : Representation
• Low Representational Gap
• Act of precision

61. “Nouns are objects, verbs are methods”

62. Is Login an object or a method?

63. Is Login an object or a method?

64. Reification
“when the construct can be treated as a value without restrictions”

65. “dependency” in product-spec allows maven to detect cycles

66. Man : Machine
Reification

67. First class construct
boolean check(List<Integer> xCoordinates, List<Integer> yCoordinates){
….
}
boolean check(List<Point> points) {
return …;
}

68. You : they (& future you)

69. You : they (& future you)
• Reification
• First-class abstractions
• First-class mechanisms

70. Selection : Projection

71. cfilter cdedup ccount cTop 5
Preprocess Aggregator

72. Data Flow Diagram

77. Orchestration : Choreography

82. Container : Component

84. Data Plane : Control Plane

87. Asks : Capabilities

89. Form : Function

90. function
form
x1 x2
x3

94. Complexity : modularity

95. Planned Design : Evolutionary Design

96. • Refactoring (continuous, opportunistic, preparatory)
• always leave the code behind in a better state than you found it
• danger of going down a rabbit hole here

97. Transformations
• ({} → nil) no code at all → code that employs nil
• (nil → constant)
• (constant → constant+) a simple constant to a more complex constant
• (constant → scalar) replacing a constant with a variable or an argument
• (statement → statements) adding more unconditional statements.
• (unconditional → if) splitting the execution path
• (scalar → array)
• (array → container)
• (statement → tail-recursion)
• (if → while)
• (statement → non-tail-recursion)
• (expression → function) replacing an expression with a function or algorithm
• (variable → assignment) replacing the value of a variable.
• (case) adding a case (or else) to an existing switch or if

98. public static int sumIterative(List<Integer> list) {
int sum = 0;
for(int element:list)
sum = sum + element;
return sum;
}
public static int sumRecursive(List<Integer> list) {
if(list.size() == 0)
return 0;
return list.get(0) + sumRecursive(list.subList(1, list.size()));
}

101. Logic : Control

102. Logic
• Workflow engines

103. Policy : Mechanism
What : How

104. Domain Specific Language
• Low Representational Gap

105. function
form
x1 x2
x3

109. Happy Path : Unhappy Path
• Railway oriented Programming

110. Optional.ofNullable(s).map(f).map(g);

111. Problem : Solution

112. Problem:Solution
• TDD (not just unit testing)
• Property based testing

115. Specificity: Genericity
• Transformations
• Refactoring

116. Composition : decomposition

117. Top down : bottom up
Working top-down, we cannot produce an acceptable decomposition of
a given problem in terms of available abstractions, but working
bottom-up, we cannot produce an acceptable composition of available
abstractions to solve a given problem.

118. function
form
Top Down
Bottom Up

119. Top down : bottom up

120. function
form
x1 x2
18 months, 3 man years
6 months, 1 man years

121. function
form
12 months

122. function
form
few minutes
RB
Sprint

123. Synthesis : Analysis

124. Convergence : Divergence
• Modify & refactor

125. Expansionist: Reductionist

126. Attention management

127. Work : Break
• Pomodoro
• Maker’s schedule : Manager’s schedule
• Sprint : Retrospective

128. I : We
• I vs we (don't venture on technologies your team doesn't understand
or should we?)

129. Read : write

130. Inside : out
• PDSC, Restli
• Domain Model

131. Local : global properties
• emergent

132. Constraints : liberties

133. Deductive Reasoning: Inductive Reasoning

134. Library : Service

135. Whole : part
• Partially applied Abstractions

136. Positivity : critical thinking

137. Comply : challenge