The document outlines essential software development concepts, focusing on principles such as code smells, refactoring, test-driven development (TDD), and the SOLID principles. It emphasizes the importance of clean code, technical debt, and iterative practices like spiking and walking skeletons for effective software design and maintenance. Additionally, it highlights personal growth strategies for software professionals, encouraging continuous learning and community engagement.

1. 1
Growing Software
& Growing Ourselves
DAN PARKIN

2. 2
WHO
AM I?
ABOUT
SOFTWARE CRAFTSMAN
AT CODURANCE
MMU ALUMNUS
ACTIVE IN THE
DEV COMMUNITY
@danpkn

3. 3
JOURNEY
SINCE MMU.
2013
TopCashback
2015
Code Computerlove
2018
Codurance

4. 44
TODAY’S MISSION.
1. 40 MINS - PROVIDE A 10,000 FOOT VIEW OF:
● Code smells & refactoring
○ Technical debt
● Test-Driven Development
○ Classicist TDD
○ Outside-In TDD
● SOLID Principles
○ Some other important principles
● Clean Code & Clean Architecture
○ What is bad code?
○ Habitability
● Spiking & Walking Skeletons
○ Feedback loops
2. 5 MINS - TIPS TO GROW AS A PROFESSIONAL
3. Q&A

5. 5
5
GROWING
SOFTWARE.

6. SOFTWARE
CHANGES.

7. 7
TECHNICAL PRACTICES I WISH
I’D KNOWN EXISTED.
SOLID PRINCIPLES
DOMAIN-DRIVEN
DESIGN: IMPORTANCE
OF CONTEXT &
LANGUAGE
CODE SMELLS
& REFACTORING
CLEAN CODE &
ARCHITECTURE
TEST-DRIVEN
DEVELOPMENT
SPIKING
& WALKING SKELETONS

8. 8

9. 9
CODE SMELLS
& REFACTORING.
DESIGN CHOICES
“Code smells are symptoms of poor design or
implementation choices”
- Martin Fowler

10. 10

11. 11

12. 12

13. 13

14. 14

15. 15

16. 16
16
The second law of thermodynamics, in principle, states
that a closed system's disorder cannot be reduced, it can
only remain unchanged or increase. A measure of this
disorder is entropy. This law also seems plausible for
software systems; as a system is modified, its disorder, or
entropy, tends to increase. This is known as software
entropy..
IVAR JACOBSON.

17. 17
TECHNICAL
DEBT / MESS.
Technical debt is a concept in software development
that reflects the implied cost of additional rework
caused by choosing an easy solution now instead of
using a better approach that would take longer.
Leads to “spaghetti code”.
REFACTORING

18. 18
ESSENTIAL VS
ACCIDENTAL
COMPLEXITY.
Essential tasks, the fashioning of the complex
conceptual structures that compose the abstract
software entity.
Accidental tasks, the representation of these abstract
entities in programming languages and the mapping of
these onto machine languages within space and speed
constraints.
REFACTORING

19. 19
BROKEN
WINDOWS
THEORY.
A criminological theory that visible signs of crime, anti-
social behavior, and civil disorder create an urban
environment that encourages further crime and
disorder, including serious crimes.
REFACTORING

20. 20
THE BOY
SCOUT RULE.
Leave the campsite cleaner than we found it.
Small, incremental improvements that cumulatively
make a large difference over time.
REFACTORING

21. 21
REFACTOR!

22. 22
TEST-DRIVEN
DEVELOPMENT.
DESIGN WITH EXAMPLES
Test-driven development (TDD) is
a software development process
that relies on the repetition of a
very short development cycle:
requirements are turned into
very specific test cases, then the
software is improved to pass the
new tests, only.

23. 23

24. 24
Sustainable pace
Go slow, to go fast

25. 2525
CLASSICIST TDD.
CLASSICIST TDD (CHICAGO SCHOOL):
● Also called, inside-out TDD
● State based verification
● Use of triangulation
● Stimulus / response pairs
● Explore one fact about the system at a time
● Useful for algorithmic problems
“As the tests get more specific, the code gets
more generic.”
- Robert C. Martin

26. 26

27. 27
Triangulation.
Test case 1
Test case 2
Test case 3
Unknown algorithm

28. 28

29. 29

30. 30

31. 31

32. 32

33. 33

34. 3434
OUTSIDE-IN TDD.
OUTSIDE-IN TDD (LONDON SCHOOL):
● Also called, mockist TDD
● Start testing at the boundaries of the system
● Focus on behaviour verification
● Interaction between objects
● Use of stubs to verify data flow
● Use of mocks to verify side effects

35. 35

36. 36

37. 37

38. 38

39. 3939
MOCKS & STUBS.
MOCKS:
● Test that a side effect did occur
● Test that a side effect didn’t occur
● Control how data flows through the SUT
STUBS:

40. 40

41. 41

42. 42

43. 43

44. 44
SOLID PRINCIPLES.
DESIGN PRINCIPLES
In object-oriented computer
programming, SOLID is a
mnemonic acronym for five
design principles intended to
make software designs more
understandable, flexible and
maintainable.

45. 45
SOLID keeps
software, soft

46. 46

47. 47
S.O.L.I.D
SINGLE RESPONSIBILITY
A class should have only a single responsibility, that is, only
changes to one part of the software's specification should be
able to affect the specification of the class.
OPEN/CLOSED
Software entities should be open for extension, but closed for
modification.
LISKOV SUBSTITUTION
Objects in a program should be replaceable with instances of
their subtypes without altering the correctness of that
program.
INTERFACE SEGREGATION
Many client-specific interfaces are better than one general-
purpose interface. Don’t force clients to depend on methods
they don’t use.
DEPENDENCY INVERSION
Depend on abstractions, not concretions.

48. 48
OTHER
PRINCIPLES.
SEPARATION OF CONCERNS
Clearly separate things that change for different reasons or at
different rates of speed.
COMMAND / QUERY SEGREGATION
Methods should either be a command that performs an action,
or a query that returns data to the caller, but not both.
TELL, DON’T ASK
“Ask the question we really want answered, instead of asking for the
information to help us figure out the answer ourselves” - Growing
Object-Oriented Software, Guided By Tests
SLAP
Single level of abstraction principle.
DRY
Don’t repeat yourself.

49. 49
CLEAN CODE
& ARCHITECTURE.
DESIGN PRINCIPLES
“Even bad code can function. But
if code isn’t clean, it can bring a
development organisation to its
knees.
Every year, countless hours and
significant resources are lost
because of poorly written code.
But it doesn’t have to be that
way.”

50. 50
EMPATHY.
CLEAN CODE

51. 51
HABITABILITY.
CLEAN CODE

52. 52
52
Habitability is the characteristic of source
code that enables people coming to the code
later in its life to understand its construction
and intentions and to change it comfortably
and confidently.
RICHARD GABRIEL.

53. 53

54. 54
WHAT IS
BAD CODE?
DOESN’T REVEAL INTENT
Abbreviations, ambiguity, unclear naming,
excessive use of comments
DIFFICULT TO REASON ABOUT
Large classes / methods, code at different levels of abstraction,
Single Responsibility Principle violation, Command Query
Segregation Principle violation
TIGHTLY COUPLED
Entities are inappropriately intimate, unable to test entities in
isolation, poor / no separation of concerns
SCARY TO CHANGE
Low / no test coverage makes changes risky, developers
scared to add features to / maintain the codebase
CLEAN CODE

55. The best metric for design
refuse is WTFs per minute.
ROBERT C. MARTIN

56. 56
KENT BECK’S
4 RULES OF
SIMPLE DESIGN
TESTS PASS
EXPRESSES INTENT
NO DUPLICATION (DRY)
SMALL
CLEAN CODE

57. 57

58. 58

59. 59
CLEAN
ARCHITECTURE. OUR APPLICATION
Business logic at the centre
with details that at edges

60. 60

61. 61

62. 62

63. 63
Technical
details
Agnostic of technical details
Technical
details

64. 64
Low level
components
High level components
Low level
components
“Protect high level
components
from low level components”

65. 65
MODULARITY.
Loosely coupled, independent units with good
separation of concerns that can be tested in isolation.
Leads to “ravioli code”.

66. 66
DDD: CONTEXT
& LANGUAGE.
DDD: UBIQUITOUS LANGUAGE
Striving to use the vocabulary of a given business domain,
not only in discussions about the requirements for a
software product, but also in discussions of design as well
the source code itself.

67. 67

68. 68
Ubiquitous Language
“Nurses administer flu vaccines to patients in standard doses”

69. 69
Ubiquitous Language

70. 70
SPIKING &
WALKING
SKELETON.
UNKNOWN UNKNOWNS
"A Walking Skeleton is a tiny implementation of the system
that performs a small end-to-end function. It need not use
the final architecture, but it should link together the main
architectural components. The architecture and the
functionality can then evolve in parallel."
- Alistair Cockburn

71. 71
FEEDBACK
LOOPS.

72. The faster we receive feedback,
the sooner we can learn and
take action.

73. 7373
TECHNICAL
SPIKE.
SPIKING:
● Experimentation
● Figure out answers to tough technical or design problems
● Reduce the risk of complications and problems
● Validate assumptions & technology choices
● Better understanding, better estimates
● Risk mitigation
● Doesn’t focus on quality, focus is on learning
● Throw away

74. A “walking skeleton” is an
implementation of the thinnest
possible slice of real functionality
that we can automatically build,
deploy, and test end-to-end
ALISTAIR COCKBURN

75. 75

76. 7676
SUMMARY.
● Take time to learn the fundamentals of software design
○ SOLID,
○ Code smells
○ Refactoring
○ Four rules of simple design
● Adopt TDD
● Protect what makes you money from low level details like frameworks
● Naming is important
○ Use a common language incorporating business terms
● Flush out uncertainty with spikes and walking skeletons

77. 77
77
GROWING OURSELVES.

78. 78
INVEST IN
YOURSELF.

79. 79
GO TO
COMMUNITY
EVENTS.

80. 80
FOLLOW
INFLUENTIAL
DEVS.

81. 81
DELIBERATE
PRACTICE.

82. 82
LEARN IDE
SHORTCUTS
& VIM.

83. 83
GROWING BY
PAIRING.

84. The amount of serendipity that will occur
in your life, your Luck Surface Area, is
directly proportional to the degree to
which you do something you're
passionate about combined with the total
number of people to whom this is
effectively communicated.
JASON ROBERTS

85. 85
Thanks.
@danpkn
https://bit.ly/2TQ69mf