Why should we practice XP engineering practices? What kind of engineering practices should we practices? How do we practice XP engineering practices?

1. 소프트웨어 장인으로 가는 길
( A Journey to Be a Software
Craftsman)
- Practicing Engineering Practices
Jaehoon Oh (jaehoon@nethru.co.kr)

2. Software Craftsmanship
Engineering Practice

3. Software
Craftsmanship
Software
Craftsman
CraftsmanCraftsmanship

4. https://www.youtube.com/watch?v=mRLLhwXyqSA
Craftsman

5. Cambridge Dictionary
- A person who is skilled at a particular craft
Longman Dictionary
- Someone who is very skilled at a particular craft
Craftsman
장인[匠人]
- 손으로 물건을 만드는 일에 종사하던 사람
- 예술 작품을 만드는 사람을 비유적으로 이르는 말

6. Someone who is very skilled at software
development.
Software Craftsman

7. How does a craftsman prove that he is
a skilled person?
QUALITY

8. How does a Software Craftsman
show that he is a skilled person?
QUALITY

9. http://blog.castsoftware.com/titanic-dilemma-the-seen-versus-the-unseen/
Readability
Flexibility
Testability
Maintainability
Cohesion
Coupling
EfficiencyCorrectness
Maintenance Cost
External
Quality
Internal Quality
(Code Quality)
Software Quality Iceberg
Test
Review

10. Craftsmanship ?
장인정신
≠

11. Craftsmanship
Cambridge Dictionary
- Skill at making things
Longman Dictionary
- The special skill that someone uses to make
something beautiful with their hands

12. Software Craftsmanship
Cambridge Dictionary
- Skill at making things Software
Longman Dictionary
- The special skill that someone uses to make
something Software beautiful with their hands

13. Agile Brief History
Waterfall Model
( Winston W. Royce)
(1970)
Concept of
“Adaptive Software Development”
( Edmends, E.A)
(1974)
Rapid App Development
(James Martin)
(1991)
Scrum (Ken Schwaber, Jeff Sutherland)
Adaptive Software Development(ASD)
(Jim Highsmith, Sam Bayer)
FDD (Jeff De Luca)
DSDM (DSDM Consortium)
XP(Kent Beck, Ward
Cunningham, Ron Jeffries)
Crystal Clear
(Alistair Cockburn)
Lean SW Development
(Mary & Tom Poppendieck)
(2003)
Agile Manifesto
(2001)
Software
Craftmanship
Manifesto
(2008)
(1995)
(1996)
https://www.visual-paradigm.com/guide/agile-software-development/what-is-agile-software-development/

14. Software Craftsmanship Manifesto
Raising the Bar
As aspiring Software Craftsmen we are raising the bar of professional software
development by practicing it and helping others learn the craft. Through this work we have
come to value:
Not Only Working Software
But Also Well-Crafted Software
Not Only Responding To Change
But Also Steadily Adding Value
Not Only Individual And Interactions
But Also A Community Of Professionals
Not Only Customer Collaboration,
But Also Productive Partnerships
That is, in pursuit of the items on left we have found the items on the right to be
indispensable.

15. Question #1. Why?
Why should we practice Engineering Practices?
Question #2. What?
What kind of Engineering Practice should we practice?
Question #3. How?
How do we practice Engineering Practices?

16. Question #1. Why?
Why should we practice
Engineering Practices?

17. Software Craftsmanship Manifesto
Raising the Bar
As aspiring Software Craftsmen we are raising the bar of professional software
development by practicing it and helping others learn the craft. Through this work we have
come to value:
Not Only Working Software
But Also Well-Crafted Software
Not Only Responding To Change
But Also Steadily Adding Value
Not Only Individual And Interactions
But Also A Community Of Professionals
Not Only Customer Collaboration,
But Also Productive Partnerships
That is, in pursuit of the items on left we have found the items on the right to be
indispensable.

18. Productivity - Business Plan
Productivity

19. Productivity - Reality
Productivity

20. Productivity Gap
Productivity

21. Why is development productivity
getting decreased
more and more?

22. http://blog.castsoftware.com/titanic-dilemma-the-seen-versus-the-unseen/
Readability
Flexibility
Testability
Maintainability
Cohesion
Coupling
EfficiencyCorrectness
Maintenance Cost
External
Quality
Internal Quality
(Code Quality)
Technical Debt

23. Quality Gap
Productivity

24. Craftsman’s Responsibility
Productivity

25. How can we keep
the development productivity
as high as we want?

26. Question #2. What?
What kind of Engineering
Practice should we practice?

27. Software Craftsmanship Manifesto
Raising the Bar
As aspiring Software Craftsmen we are raising the bar of professional software development
by practicing it and helping others learn the craft. Through this work we have come to value:
Not Only Working Software
But Also Well-Crafted Software
Not Only Responding To Change
But Also Steadily Adding Value
Not Only Individual And Interactions
But Also A Community Of Professionals
Not Only Customer Collaboration,
But Also Productive Partnerships
That is, in pursuit of the items on left we have found the items on the right to be
indispensable.

29. Relationships Between Engineering Practices
7
8 8
6
6

30. + Legacy Code
Refactoring

31. Refactoring

32. Refactoring
is a discplined technique for restructuring an existing body
of code,
altering its internal structure without changing its external
behavior.

33. Refactoring - Cost Per Feature

34. Refactoring
You should prove that
you didn’t change the existing behaviors
when you refactor code.

35. Refactoring and Test
Suppose that you have changed a line of code.
There are about 10,000 functionalities in your SW.
How many functionalities should you test?

36. Test Driven Development

37. Software Behavior
Redefinition of Testing
Specified Unspecified

38. Tester
Programmer
Requirement
Specification
Analysis Design Code Test
Analysis
TC
Design
Test
Execution
Fix
Bug
Test
Execution
Fix
Bug
Test
Execution
...
How do we collaborate?
Test Test

39. https://www.infoq.com/news/2009/12/testing-or-checking/
http://www.skylinetechnologies.com/Insights/Skyline-Blog/July-2013/Test-Planning-Part-1-Improving-Your-Test-Results
시스템이 요구사항대로
동작하는지를 검증하는 것은
테스팅인가?

40. Software Testing
Redefinition of Testing
Specified Unspecified
Confirmation
Verification
Validation
Exploration
Discovery Investigation
Learning
Confirming existing behaviors Finding new information
Checking!!! Testing

41. Who is responsible for that
the implementation meets
specifications?

42. Programmer Test ⇒ Programmer Check
Programmer should prove that
the implementation meets specifications
by checking its’ behavior.

43. Tester
Programmer
Requirement
Specification
Analysis Design Code Test
Analysis
TC
Design
Test
Execution
Fix
Bug
Test
Execution
Fix
Bug
Test
Execution
...
How do we have to collaborate?
Test Test
Check
Check Check

44. Programmer Check Strategies
Strategy Description
Debug Driven Development
Manual Test
No Automated Test
Use Debugger
Test After Development
Write test code
after writing production code
Test First Development
Write all test cases
before writing production code
Test Driven Development Write a failing test case, make it pass and refactor

45. TDD Cycle
Writing
a Failing
Test
Make It
Pass
Refactor
Requirement
(User Story)
Production Code
( Solution Space )
Test CodeProblem Space

46. Test Code
Requirement
(User Story)
function
f(x)
Abstract
(Easy to misunderstand)
Specific
( Easy to understand)

47. TDD Cycle
Writing
a Failing
Test
Make It
Pass
Refactor
Requirement
(User Story)
Problem Space
1. Easy
2. Simple
1. Simple
2. Fast
1. Find a Logic
2. Make it duplicate
3. Remove Duplication
1. Change small
2. Run Test
3. Go Back If fail

48. Make It Pass
TDD Cycle
TC1 TC1
TC2
TC1
TC2
TC3
TC1
TC2
TC3
Writing a Failing Test
TC1 TC1
TC2
TC1
TC2
TC3
TC1
TC2
TCn
TC3
TCn
Refactor
TC1 TC1
TC2
TC1
TC2
TC3
TC1
TC2
TC3
TCn
TC1
TC2
TC3

49. TDD - Knowledge
# of Test Case
Amount of
Knowledge
Requirement
Solution

50. Development Phase in Waterfall
Analysis
Design
Code
Test

51. Development Phase in TDD
Analysis
Test Code Design
Test Code Design
Analysis Test Code Design
Test Code Design

52. Legacy Code Refactoring

53. Legacy Code
What is the Legacy Code?
Old
The code that I didn’t write!!
Hard to Understand
Hard to Change
Hard to Maintain

54. Legacy Code
“Code Without Test”
( Michael Feathers )
People are writing legacy code right now, maybe on your project.
( http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf )

55. Adding a new feature
Legacy Code New FeaturePreserve Existing Feature
You should prove that you don’t break the existing features.

56. Legacy Code Refactoring Algorithm
1. 생성자 테스트 작성 ( 테스트 픽스처 생성 비용 검사 )
2. 테스트 커버리지 측정
3. 커버리지 데이터를 기반으로 테스트 되지 않은 코드를
커버할 새 테스트를 작성( Characterization Test )
4. 기능을 100% 커버할 때까지 2,3 단계를 반복
5. 리팩토링 시작

57. Production Code Only
(Legacy Code)
Legacy Code Refactoring
• Potential Bug Injection
• Fear to change code
• Insufficient Confidence
Production Code Production Code
Test
Code
Production Code + Test Code
• Shelter to Production Code
• Bugs found as soon as It is injected
• No Fear To Change Code
• Enough Confidence

58. Legacy Code Refactoring - One Big Step
One Big Step

59. Legacy Code Refactoring
Extract Method
Test
Move Method
Test
Extract Subclass + Push Down
Test
Extract Subclass + Push Down
Test
Sm
all Baby
Steps

60. Simple Design

61. Skills And Knowledge about Design
Low Coupled
High Cohesive
SRP
OCP
LSP
ISP
DIP
RREP
CCP
CRP
SDP
ADP
SAP
Coding Convention
KISS
Boy Scout Rule
TDD
Refactoring
Software Craftsmanship
ATDD
Code Smell
Don’t Repeat Yourself
Simple Design
You Are Not Gonna Need It!
Design Pattern
Unit Test
Test Automation
Separation of Concerns
Role, Responsibilities, Collaborations
Domain Driven Design
POSA
Analysis PatternUML
Legacy Code Refactoring
Law Of Demeter

62. Up Front Design
How big is your up-front design?
When do you design your code?
How much will you pay for up-front design if you can change your design at no
cost?

63. Design Spectrum
Over EngineeringNo Design
Simple Design

64. Simple Design
정의
- 현재까지의 문제를 해결하는 가장 단순한 설계
- 현재까지 발생한 변화의 방향을 쉽게 해결할 수 있는 설계

65. Simple Design
Rules of Code Simplicity by Kent Beck
● the code is verified by automated tests, and all such tests pass
● the code contains no duplication
● the code expresses separately each distinct idea or responsibility
● the code is composed of the minimum number of components (classes,
methods, lines) compatible with the first three criteria
https://www.agilealliance.org/glossary/rules-of-simplicity/

66. Simple Design
Principles for Simple Design
● design is an ongoing activity, which includes refactoring and heuristics such as YAGNI
● design quality is evaluated based on the rules of code simplicity
● all design elements such as design patterns, plugin-based architectures, etc. are seen as
having costs as well as benefits, and design costs must be justified;
● design decisions should be deferred until the "last responsible moment", so as to collect
as much information as possible on the benefits of the chosen option before incurring its
costs.
https://www.agilealliance.org/glossary/simple-design

67. Question #3. How?
How do we practice
Engineering Practices?
( A journey to be a software craftsman )

68. Start from Reading Books

69. Reading Books
is not enough.
Why?

70. Tacit Knowledge
Once shared, it belongs to everyone.
Can be seen “above the water”
Tangible
Visible
Public
Can be accessed on only a first-person basis
Hidden “Underwater”
Intangible
Invisible
Private

71. What is the most effective way
to learn
the tacit knowledge?

72. Work + Shop in the Medieval Period
A medieval baker with his apprentice, The Bodleian Library, Oxford.
Pair Baking!!

73. Pair Programming

74. Mob Programming
Copy the Thinking Process

75. CSM Workshops
● Certificated Scrum Master, May 2014
● What I learned?
○ What I read differs from what it really means

76. Michael Feathers Workshop
● October, 2014
● First Programming Workshop
● Legacy Code Refactoring
○ How to break dependency
○ How to change legacy code in baby
steps.
● What I learned?
○ How to refactor legacy code
○ How to transfer knowledge and
experience!!!

77. CSD Workshop
● Odd-e At Singapore
● 1 Week Sprint
● What I Learned
○ How to make a potentially shippable
product increment in a sprint
○ Specification Workshop
○ ATDD
○ TDD
○ ...

78. Steve Freeman Workshop
• April, 2015
• Acceptance Test Driven Development

79. ● A Kind of Deliberate Practice
● Sites
○ http://codekata.com/
○ http://rosettacode.org/wiki/Rosetta_Code
○ http://www.exercism.io/
○ http://www.cyber-dojo.org
○ ...
Coding Kata

80. ● Sites
○ https://www.industriallogic.com/elearning/
○ http://www.cleancoders.com
Online Training

81. Software Craftsmanship Manifesto
Raising the Bar
As aspiring Software Craftsmen we are raising the bar of professional software development
by practicing it and helping others learn the craft. Through this work we have come to value:
Not Only Working Software
But Also Well-Crafted Software
Not Only Responding To Change
But Also Steadily Adding Value
Not Only Individual And Interactions
But Also A Community Of Professionals ( Practice )
Not Only Customer Collaboration,
But Also Productive Partnerships
That is, in pursuit of the items on left we have found the items on the right to be
indispensable.

82. CoP - Closed Agile Talking Group
● First Meetup : 2014.5
● Last Meetup : 2017.?.?
● Once a week
● Meet almost every week
● Product : Agile Workshop
o Agile Introduction
o Agile Requirement
o Agile Mindset
o Test Driven Development
o Acceptance Test Driven
Development

83. CoP - Xper Engineering Practice
● Once a Month
● Every First Monday of the Month
● Topics : TDD, Legacy Code Refactoring, Pair Programming, ...

84. Teaching Others - Learning Pyramid

85. Connected to the Global Agile Leaders

87. Great Programmer?
“I'm not a great programmer;
I'm just a good programmer
with great habits.”

88. Great Habits
Reflection leads to all the other habits.
1. How’d that last hour go?
2. What could I have done better?
3. What do I want to try next time?
https://www.quora.com/Kent-Beck-You-have-been-quoted-saying-you-are-not-a-great-programmer-but-rather-a-good-programmer-with
-great-habits-What-are-these-great-habits

89. Thank You!