The document discusses the history and development of the software craftsmanship movement. It began in the 1990s with ideas around treating software development as a craft similar to other skilled trades. In the 2000s, these ideas saw renewed interest through Robert Martin's talks advocating for craftsmanship over poor quality code. This led to the creation of the Software Craftsmanship Manifesto, which outlined principles for developers to focus on quality, learning, and sharing knowledge. The document examines issues that led to interest in craftsmanship such as poor code quality and a lack of practical skills training. It presents craftsmanship as an alternative that emphasizes pride in work, learning from others, and stakeholder trust through

1. Picture: http://www.flickr.com/photos/drhurn/1985687/sizes/m/in/photostream/
1

2. Picture: http://www.flickr.com/photos/psd/2423294079/sizes/l/in/photostream/
2

3. About me
3

4. Most of this presentation is based on the work of Robert Martin and Corey Haines
4

5. 5

6. OOPSLA 1991
Object-Oriented Programming, Systems, Languages & Applications Conference
Bruce Anderson workshop “Towards a Software Architecture Handbook”
Dedicated to developing a handbook for software architects
Richard Helm, Ralph Johnson, John Vlissides and Erich Gamma met here
Collaborated for couple of years to produce “Design Patterns” - GOF
6

7. OOPSLA 1998
Bruce Anderson workshop “Software as a Studio Discipline”
Discuss whether developing software is a careful blend of artistry and discipline
Pete McBreen inspired
In 2001, published book “Software Craftsmanship”
Main theme:
• Software engineering has run its course
• Building software systems requires set of skills and experiences beyond just book
learning, training courses, methodologies, and certifications
7

8. Book presented a craftsman paradigm in which apprentice software developer learns
from journeyman like other craftsman based professions
• Software is a craft: part art, part skill
• Developers should be measured on quality of work, ability to deliver value to
business and be accountable for what they produce.
At the time it was published, it did not generate much noise or interest and did not
become a hit like the GoF book.
Picture: http://www.flickr.com/photos/25507200@N07/3120849218/
8

9. Agile 2008 – Toronto
Keynote address by uncle Bob
Reviewed Agile manifesto
Proposed fifth value to agile manifesto: Craftsmanship over crap
Huge stage to bring up the same concepts again and created a lot of discussion
9

10. A week later Robert Martin revised it to craftsmanship over execution
Most software development teams execute, but they don’t care. We value execution,
but we value craftsmanship more.
“We're tired of writing crap. We are tired of embarrassing ourselves and our
employers by delivering lousy software. We have had enough of telling our
customers to reboot at midnight. We don't want bug lists that are a thousand pages
long. We don't want code that grows more tangled and corrupt with every passing
day. We're tired of doing a bad job. We want to start doing a good job.”
http://cleancoder.posterous.com/software-craftsmanship-things-wars-commandmen
Did not result in change to manifesto, but started a movement of its own.
December 2008, group of aspiring software craftsmen got together and tried to solve
some problems they were facing
Came up with a statement of things they believe in and crafted another manifesto,
the Software Craftsmanship manifesto
10

11. Software Craftsmanship manifesto
11

12. Agile 2008 – Toronto
Keynote address by uncle Bob
Reviewed Agile manifesto
Proposed fifth value to agile manifesto: Craftsmanship over crap
Huge stage to bring up the same concepts again and created a lot of discussion
12

13. They felt that we are heading in a bad direction.
The state of software development was going downhill.
13

14. Theory vs. practice
Mismatch with teaching and what is needed for work
Strong theoretical knowledge but can’t write good code
Picture:
http://www.flickr.com/photos/sakeeb/4647211575/sizes/m/in/photostream/
14

15. Popularity of Scrum.
Scrum focuses on process but does not prescribe technical practices.
Ken Schwaber said that we made a fundamental assumption that was wrong
Developers smart enough to come up with their own practices
But developers spent careers working in large cycles. They were used to it. waiting for
9 months before coding or before QA
Now they have to figure out how to do things in 30 days or even in 2 weeks.
Agile and Scrum requires skilled developers that know how to keep code base healthy
Delivering software every 2 to 4 weeks only possible if build up and keep code highly
maintainable
Picture: www.mountaingoatsoftware.com/scrum
15

16. Robert Martin bad code video
16

17. Place holder
17

18. Big ball of mud most popular way to design and architect software
Includes Greenfield projects that have full benefit of hindsight regarding bad design
approaches of past
Picture:
http://www.flickr.com/photos/24322735@N07/2393833499/sizes/m/in/photostrea
m/
18

19. Code unreadable and looked like spaghetti code jungle
19

20. Become sloppy
Use duck tape to fix things
The whole code is covered with duck tape.
Picture:
http://www.flickr.com/photos/wwworks/4471608005/sizes/m/in/photostream/
20

21. In a minefield
Anything you touch might break and explode
Now easier to do it all over again than to read and figure out other people’s code
Picture:
http://www.flickr.com/photos/timrich26/3308513067/sizes/m/in/photostream/
21

22. Need tools like crap4j - Change Risk Analyzer and Predictor
CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m)
m = method
comp(m) = Cyclometric complexity of method
m. cov(m) = Test code coverage for method m.
Crap gap measure
22

23. Most interesting man in the world
Picture: http://imgur.com/y7Hm9?full
23

24. Software craftsmen: good software does not come from process
Comes from people who care about it
People have pride in their work
Stand by what they do
Willing to learn from others to improve
By sharing they bring up knowledge of entire team and company
Building code requires more than theoretical knowledge, it requires tacit knowledge
and experience.
24

25. We Care
We consider it our responsibility
to gain the trust of the businesses we serve;
therefore, we
take our customer's problems as seriously as they do and
stake our reputation on the quality of the work we produce.
We Practice
We consider it our responsibility
to write code that is defect-free, proven, readable, understandable and malleable;
therefore, we
follow our chosen practices meticulously even under pressure and
practice our techniques regularly.
We Learn
We consider it our responsibility
to hone our craft in pursuit of mastery;
therefore, we
continuously explore new technologies and
read and study the work of other craftsmen.
We Share
We consider it our responsibility
to perpetuate the craft of Software;
therefore, we
enlist apprentices to learn it and
actively engage other craftsmen in dialogue and practice.
25

26. We Care about quality. We stake our reputation on the quality of the work we
produce.
We Care
We consider it our responsibility
to gain the trust of the businesses we serve;
therefore, we
take our customer's problems as seriously as they do and
stake our reputation on the quality of the work we produce.
26

27. We Practice: We practice our techniques regularly and follow our practices even
under pressure in order to write defect-free, proven, readable, understandable and
malleable
We Practice
We consider it our responsibility
to write code that is defect-free, proven, readable, understandable and malleable;
therefore, we
follow our chosen practices meticulously even under pressure and
practice our techniques regularly.
27

28. We Learn: we continuously explore new technologies, read and study the work of
other craftsmen.
We Learn
We consider it our responsibility
to hone our craft in pursuit of mastery;
therefore, we
continuously explore new technologies and
read and study the work of other craftsmen.
28

29. We Share: we look for newcomers and actively engage other craftsmen in dialogue
and practice
We Share
We consider it our responsibility
to perpetuate the craft of Software;
therefore, we
enlist apprentices to learn it and
actively engage other craftsmen in dialogue and practice.
Picture:
http://www.flickr.com/photos/das_butzele/227637183/sizes/z/in/photostream/
29

30. Disciplines
30

31. TDD – verifies that our code works and makes it possible to refactor and constantly
improve code over time.
TDD: Follow 3 rules: 1) not allowed to write production code until you have a failing
unit test, 2) you are not allowed to write more of unit test than is sufficient to fail
(not compile is failing), 3) you are not allowed to write more production code than is
sufficient to pass. This forces us to keep the code executing all the time. Tests make
the software flexible and maintainable.
31

32. CI: Use tools like Hudson, CruiseControl, Bamboo, and TeamCity. If build fails,
immediately fix build.
32

33. Pairing: If you don’t want to code pair, at least make sure team is communicating,
sharing and working closely together.
33

34. Pride and attitude that QA should find nothing
34

35. Principles
35

36. Apply the boy scout rule: Always leave camp ground cleaner than way you found it.
That is, whenever you work on a class or function, spend some extra time to refactor
it and clean it a little.
Picture:
http://www.flickr.com/photos/fotoecke/5177140233/sizes/m/in/photostream/
36

37. Apply Extract till you drop: Function size should be small. Keeping extracting until you
can no longer extract function. This takes all the concepts in the function puts them
in well named places.
37

38. No argument is best argument. Functions should have smallest number of arguments
possible. Try not to exceed 2 arguments. Do not pass Booleans as arguments; instead
create two well named functions.
Picture:
http://www.flickr.com/photos/drinksmachine/3732782275/sizes/m/in/photostream/
38

39. Use long names to be as descriptive as possible.
39

40. Avoid duplication. Do not copy and paste.
Picture: http://www.flickr.com/photos/popilop/331357312/sizes/z/in/photostream/
40

41. Design Patterns
41

42. SOLID Principles
S SRP Single responsibility principle the notion that an object should have only a
single responsibility.
O OCP Open/closed principle the notion that “software entities … should be open for
extension, but closed for modification”.
L LSP Liskov substitution principle the notion that “objects in a program should be
replaceable with instances of their subtypes without altering the correctness of that
program”.
I ISP Interface segregation principle the notion that “many client specific interfaces
are better than one general purpose interface.”
D DIP Dependency inversion principle the notion that one should “Depend upon
Abstractions. Do not depend upon concretions.”[
Dependency injection is one method of following this principle.
42

43. Picture: http://lostechies.com/gabrielschenker/files/2011/03/giant_2.jpg
43

44. Picture:
http://lostechies.com/derickbailey/files/2011/03/OpenClosedPrinciple2_2C596E17.j
pg
44

45. Picture:
http://lostechies.com/derickbailey/files/2011/03/LiskovSubtitutionPrinciple_52BB51
62.jpg
45

46. Picture:
http://lostechies.com/derickbailey/files/2011/03/InterfaceSegregationPrinciple_6021
6468.jpg
46

47. Picture:
http://lostechies.com/derickbailey/files/2011/03/DependencyInversionPrinciple_027
8F9E2.jpg
47

48. Abstract away volatility: look at what is likely to change and separate it from what is
not likely to change. (do not mix gui with business rules).
48

49. http://www.flickr.com/photos/70981241@N00/3979767112/
Decouple from others: write stubs to ensure your code can run and to define your
interface
49

50. http://www.flickr.com/photos/11904001@N00/3983980813/
Work in small increments
Use progressive widening: Add a small feature from top to bottom (GUI to database)
Use progressive deepening: Get something working in one layer and then move it
down to other layers. 1st make it work, then make it right, then make it fast.
Avoid grand redesigns. They generally do not work very well. A “tiger” team will
constantly be trying to catch up with maintenance team.
50

51. Short iterations (1 or 2 weeks). Plan, code, testing, documentation (complete cycle
resulting in deployable software.
Participate in the definition process by demonstrating working code.
51

52. Commission instead of omission. It is better to experiment than to wait.
Never be blocked: always find some way to make progress
Picture: http://www.flickr.com/photos/7821771@N05/4679360979/
52

53. You Ain’t gonna need it. Avoid turgid viscous architectures. They do harm than good.
They slow you down. Don’t try to create a solution for all possible (imaginable) cases.
Just try to solve the problem at hand use a simple architecture. Use good coding
techniques (like decoupling and SRP) and adding in new cases as they are need
should be easy.
Picture: http://www.flickr.com/photos/97041449@N00/5261698908/
53

54. Automate everything. Playing with system should be explorative testing. The other
vast majority of testing should be automated. Builds should be automated.
Deployments should be automated.
Check out the book “Continuous Delivery: Reliable Software Releases through Build,
Test, and Deployment Automation” by Jez Humble and David Farley
54

55. Test through the right interface. Do not test business rules through the GUI. Test GUI
connected to a dummy (mock) layer.
Picture: http://www.flickr.com/photos/37164718@N02/5365226277/
55

56. Don’t jump into the debugger. Look at the code 1st. Use TDD. Debugger should be
last resort.
Picture: http://www.flickr.com/photos/71962092@N00/2874328851/
56

57. Clean code: Only way to go fast is to slow down a minute and write clean code.
Readable, obvious, small functions, good names
Don’t write bad code: It does not only slow down others months from now but will
slow you down immediately.
57

58. Software craftsmanship is about pride in work, team work, mentorship, improving
skills, practicing
Yet there is some disagreement
58

59. Not everyone agrees
Dan North, and David Harvey
Argue software craftsmanship manifesto is weak
Just adds riders or extensions to agile manifesto
Most already covered in agile principles
59

60. Principle #9: continuous attention to technical excellence and good design enhances
agility.
60

61. 2nd, manifesto is tame
Manifesto - a statement of belief, a call-to-arms, feisty, opinionated, and brash.
Marx and Angels communist manifesto
Futurist manifesto
SCUM manifesto
All compelling, persuasive, controversial and polarizing
Should be something we can disagree with
No reasonable person can disagree with software craftsmanship manifesto
No one can say they don’t care about adding value, create community of
professionals, having productive partnerships and writing quality software.
Not much of a manifesto
61

62. Manifesto is attack on software engineering and scientific research
Manifesto is giving permission new generation to ignore all lessons learned from
software engineering
Lessons like the works of DeMarco, Yourdon, Parnas, Dijkstra, Hoare, Weinberg.
62

63. Language matters
choosing inappropriate metaphors, like craftsman, apprentice, journeyman, increases
gap between development and business.
Software developers have their own definition of craftsmanship, but what matters is
perception of customers
Associate craft with quality at a flea-market or craft fair - not something can really
rely on
http://www.flickr.com/photos/58289610@N00/3610407879/
63

64. Terms "Master", "Journeyman", and "Apprentice“ bring up secretive guilds of middle
ages with ritual, mysticism, and intrigue
Software craftsmen should be egoless, humble, with focus on outcome rather than
code or process
64

65. Manifesto brought people together and made it easier for them to roll out some
ideas on how to practice
65

66. Code katas - Dave Thomas from pragmatic programmers
Small problems to solve
Uncle Bob switched to practice on a solution instead
Like martial arts and how you repeat small motions and practice them until they
become natural reflexes
Do it over and over again until it becomes reflex
Katacasts.com – Corey Haines has various screencasts known as katacast that show
folks practicing a small kata
66

67. Example Bowling Kata, Poker Kata, Supermarket Kata, Tennis Kata
Picture: http://www.flickr.com/photos/49715404@N00/3267627038/
67

68. Code retreats started worldwide
Developers get together on Saturday for full day of practice
Work on Conway’s game of life using technique “TDD as if you meant it”
Focuses on TDD being all about evolutionary design
Pair-up, work on it for 45 minutes, then delete code, swap pairs and do it again
68

69. 2 companies swap employee for week
Employees learn practices of another company and come back and try to improve
their own environment
69

70. Craftsman journey – you go to company for 1 week and learn what they do
Instead of going to conference, company will give you time off to go and work and
learn what others are doing
70

71. Craftsman spikes are side projects that you use to practice craftsmanship
Companies offers employees 20% time to work on side projects
71

72. Software craftsmanship conferences established and 2 held each year, one in the UK
and one in the US
Several Software Craftsmanship User groups started
72

73. What does all this mean to you?
73

74. 74

75. 75

76. Contact Info
76

77. 77

78. 78

79. 79

80. 80

81. 81