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

1

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

2

About me

3

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

4

5

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

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

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

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

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

Software Craftsmanship manifesto

11

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

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

13

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

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

Robert Martin bad code video

16

Place holder

17

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/photostream/

18

Code unreadable and looked like spaghetti code jungle

19

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

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

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

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

23

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

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

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

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

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

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

Disciplines

30

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

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

32

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

33

Pride and attitude that QA should find nothing

34

Principles

35

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

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

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

Use long names to be as descriptive as possible.

39

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

40

Design Patterns

41

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

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

43

Picture: http://lostechies.com/derickbailey/files/2011/03/OpenClosedPrinciple2_2C596E17.jpg

44

Picture: http://lostechies.com/derickbailey/files/2011/03/LiskovSubtitutionPrinciple_52BB5162.jpg

45

Picture: http://lostechies.com/derickbailey/files/2011/03/InterfaceSegregationPrinciple_60216468.jpg

46

Picture: http://lostechies.com/derickbailey/files/2011/03/DependencyInversionPrinciple_0278F9E2.jpg

47

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

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

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

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

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

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

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

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

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

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

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

58

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

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

60

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

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

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

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

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

65

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

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

67

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

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

69

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

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

71

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

What does all this mean to you?

73

74

75

Contact Info

76

77

78

79

80

81