Software craftsmanship - Imperative or Hype

792 views
721 views

Published on

This talk was given by Fadi Stephan at the recent South African Scrum Gathering

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
792
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Software craftsmanship - Imperative or Hype

  1. 1. Picture: http://www.flickr.com/photos/drhurn/1985687/sizes/m/in/photostream/ 1
  2. 2. Picture: http://www.flickr.com/photos/psd/2423294079/sizes/l/in/photostream/ 2
  3. 3. About me 3
  4. 4. Most of this presentation is based on the work of Robert Martin and Corey Haines 4
  5. 5. 5
  6. 6. OOPSLA 1991Object-Oriented Programming, Systems, Languages & Applications ConferenceBruce Anderson workshop “Towards a Software Architecture Handbook”Dedicated to developing a handbook for software architectsRichard Helm, Ralph Johnson, John Vlissides and Erich Gamma met hereCollaborated for couple of years to produce “Design Patterns” - GOF 6
  7. 7. OOPSLA 1998Bruce Anderson workshop “Software as a Studio Discipline”Discuss whether developing software is a careful blend of artistry and disciplinePete McBreen inspiredIn 2001, published book “Software Craftsmanship”Main theme:• Software engineering has run its course• Building software systems requires set of skills and experiences beyond just booklearning, training courses, methodologies, and certifications 7
  8. 8. Book presented a craftsman paradigm in which apprentice software developer learnsfrom 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 tobusiness and be accountable for what they produce.At the time it was published, it did not generate much noise or interest and did notbecome a hit like the GoF book.Picture: http://www.flickr.com/photos/25507200@N07/3120849218/ 8
  9. 9. Agile 2008 – TorontoKeynote address by uncle BobReviewed Agile manifestoProposed fifth value to agile manifesto: Craftsmanship over crapHuge stage to bring up the same concepts again and created a lot of discussion 9
  10. 10. A week later Robert Martin revised it to craftsmanship over executionMost software development teams execute, but they don’t care. We value execution,but we value craftsmanship more.“Were tired of writing crap. We are tired of embarrassing ourselves and ouremployers by delivering lousy software. We have had enough of telling ourcustomers to reboot at midnight. We dont want bug lists that are a thousand pageslong. We dont want code that grows more tangled and corrupt with every passingday. Were tired of doing a bad job. We want to start doing a good job.”http://cleancoder.posterous.com/software-craftsmanship-things-wars-commandmenDid 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 solvesome problems they were facingCame up with a statement of things they believe in and crafted another manifesto,the Software Craftsmanship manifesto 10
  11. 11. Software Craftsmanship manifesto 11
  12. 12. Agile 2008 – TorontoKeynote address by uncle BobReviewed Agile manifestoProposed fifth value to agile manifesto: Craftsmanship over crapHuge stage to bring up the same concepts again and created a lot of discussion 12
  13. 13. They felt that we are heading in a bad direction.The state of software development was going downhill. 13
  14. 14. Theory vs. practiceMismatch with teaching and what is needed for workStrong theoretical knowledge but can’t write good codePicture:http://www.flickr.com/photos/sakeeb/4647211575/sizes/m/in/photostream/ 14
  15. 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 wrongDevelopers smart enough to come up with their own practicesBut developers spent careers working in large cycles. They were used to it. waiting for9 months before coding or before QANow 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 healthyDelivering software every 2 to 4 weeks only possible if build up and keep code highlymaintainablePicture: www.mountaingoatsoftware.com/scrum 15
  16. 16. Robert Martin bad code video 16
  17. 17. Place holder 17
  18. 18. Big ball of mud most popular way to design and architect softwareIncludes Greenfield projects that have full benefit of hindsight regarding bad designapproaches of pastPicture:http://www.flickr.com/photos/24322735@N07/2393833499/sizes/m/in/photostream/ 18
  19. 19. Code unreadable and looked like spaghetti code jungle 19
  20. 20. Become sloppyUse duck tape to fix thingsThe whole code is covered with duck tape.Picture:http://www.flickr.com/photos/wwworks/4471608005/sizes/m/in/photostream/ 20
  21. 21. In a minefieldAnything you touch might break and explodeNow easier to do it all over again than to read and figure out other people’s codePicture:http://www.flickr.com/photos/timrich26/3308513067/sizes/m/in/photostream/ 21
  22. 22. Need tools like crap4j - Change Risk Analyzer and PredictorCRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m)m = methodcomp(m) = Cyclometric complexity of methodm. cov(m) = Test code coverage for method m.Crap gap measure 22
  23. 23. Most interesting man in the worldPicture: http://imgur.com/y7Hm9?full 23
  24. 24. Software craftsmen: good software does not come from processComes from people who care about itPeople have pride in their workStand by what they doWilling to learn from others to improveBy sharing they bring up knowledge of entire team and companyBuilding code requires more than theoretical knowledge, it requires tacit knowledgeand experience. 24
  25. 25. We CareWe consider it our responsibility to gain the trust of the businesses we serve; therefore, we take our customers problems as seriously as they do and stake our reputation on the quality of the work we produce.We PracticeWe 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 LearnWe 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 ShareWe 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. 26. We Care about quality. We stake our reputation on the quality of the work weproduce.We CareWe consider it our responsibility to gain the trust of the businesses we serve; therefore, we take our customers problems as seriously as they do and stake our reputation on the quality of the work we produce. 26
  27. 27. We Practice: We practice our techniques regularly and follow our practices evenunder pressure in order to write defect-free, proven, readable, understandable andmalleableWe PracticeWe 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. 28. We Learn: we continuously explore new technologies, read and study the work ofother craftsmen.We LearnWe 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. 29. We Share: we look for newcomers and actively engage other craftsmen in dialogueand practiceWe ShareWe 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. 30. Disciplines 30
  31. 31. TDD – verifies that our code works and makes it possible to refactor and constantlyimprove code over time.TDD: Follow 3 rules: 1) not allowed to write production code until you have a failingunit 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 issufficient to pass. This forces us to keep the code executing all the time. Tests makethe software flexible and maintainable. 31
  32. 32. CI: Use tools like Hudson, CruiseControl, Bamboo, and TeamCity. If build fails,immediately fix build. 32
  33. 33. Pairing: If you don’t want to code pair, at least make sure team is communicating,sharing and working closely together. 33
  34. 34. Pride and attitude that QA should find nothing 34
  35. 35. Principles 35
  36. 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 refactorit and clean it a little.Picture:http://www.flickr.com/photos/fotoecke/5177140233/sizes/m/in/photostream/ 36
  37. 37. Apply Extract till you drop: Function size should be small. Keeping extracting until youcan no longer extract function. This takes all the concepts in the function puts themin well named places. 37
  38. 38. No argument is best argument. Functions should have smallest number of argumentspossible. Try not to exceed 2 arguments. Do not pass Booleans as arguments; insteadcreate two well named functions.Picture:http://www.flickr.com/photos/drinksmachine/3732782275/sizes/m/in/photostream/ 38
  39. 39. Use long names to be as descriptive as possible. 39
  40. 40. Avoid duplication. Do not copy and paste.Picture: http://www.flickr.com/photos/popilop/331357312/sizes/z/in/photostream/ 40
  41. 41. Design Patterns 41
  42. 42. SOLID PrinciplesS SRP Single responsibility principle the notion that an object should have only asingle responsibility.O OCP Open/closed principle the notion that “software entities … should be open forextension, but closed for modification”.L LSP Liskov substitution principle the notion that “objects in a program should bereplaceable with instances of their subtypes without altering the correctness of thatprogram”.I ISP Interface segregation principle the notion that “many client specific interfacesare better than one general purpose interface.”D DIP Dependency inversion principle the notion that one should “Depend uponAbstractions. Do not depend upon concretions.”[Dependency injection is one method of following this principle. 42
  43. 43. Picture: http://lostechies.com/gabrielschenker/files/2011/03/giant_2.jpg 43
  44. 44. Picture:http://lostechies.com/derickbailey/files/2011/03/OpenClosedPrinciple2_2C596E17.jpg 44
  45. 45. Picture:http://lostechies.com/derickbailey/files/2011/03/LiskovSubtitutionPrinciple_52BB5162.jpg 45
  46. 46. Picture:http://lostechies.com/derickbailey/files/2011/03/InterfaceSegregationPrinciple_60216468.jpg 46
  47. 47. Picture:http://lostechies.com/derickbailey/files/2011/03/DependencyInversionPrinciple_0278F9E2.jpg 47
  48. 48. Abstract away volatility: look at what is likely to change and separate it from what isnot likely to change. (do not mix gui with business rules). 48
  49. 49. http://www.flickr.com/photos/70981241@N00/3979767112/Decouple from others: write stubs to ensure your code can run and to define yourinterface 49
  50. 50. http://www.flickr.com/photos/11904001@N00/3983980813/Work in small incrementsUse 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 itdown 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 willconstantly be trying to catch up with maintenance team. 50
  51. 51. Short iterations (1 or 2 weeks). Plan, code, testing, documentation (complete cycleresulting in deployable software.Participate in the definition process by demonstrating working code. 51
  52. 52. Commission instead of omission. It is better to experiment than to wait.Never be blocked: always find some way to make progressPicture: http://www.flickr.com/photos/7821771@N05/4679360979/ 52
  53. 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 codingtechniques (like decoupling and SRP) and adding in new cases as they are needshould be easy.Picture: http://www.flickr.com/photos/97041449@N00/5261698908/ 53
  54. 54. Automate everything. Playing with system should be explorative testing. The othervast 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. 55. Test through the right interface. Do not test business rules through the GUI. Test GUIconnected to a dummy (mock) layer.Picture: http://www.flickr.com/photos/37164718@N02/5365226277/ 55
  56. 56. Don’t jump into the debugger. Look at the code 1st. Use TDD. Debugger should belast resort.Picture: http://www.flickr.com/photos/71962092@N00/2874328851/ 56
  57. 57. Clean code: Only way to go fast is to slow down a minute and write clean code.Readable, obvious, small functions, good namesDon’t write bad code: It does not only slow down others months from now but willslow you down immediately. 57
  58. 58. Software craftsmanship is about pride in work, team work, mentorship, improvingskills, practicingYet there is some disagreement 58
  59. 59. Not everyone agreesDan North, and David HarveyArgue software craftsmanship manifesto is weakJust adds riders or extensions to agile manifestoMost already covered in agile principles 59
  60. 60. Principle #9: continuous attention to technical excellence and good design enhancesagility. 60
  61. 61. 2nd, manifesto is tameManifesto - a statement of belief, a call-to-arms, feisty, opinionated, and brash.Marx and Angels communist manifestoFuturist manifestoSCUM manifestoAll compelling, persuasive, controversial and polarizingShould be something we can disagree withNo reasonable person can disagree with software craftsmanship manifestoNo one can say they don’t care about adding value, create community ofprofessionals, having productive partnerships and writing quality software.Not much of a manifesto 61
  62. 62. Manifesto is attack on software engineering and scientific researchManifesto is giving permission new generation to ignore all lessons learned fromsoftware engineeringLessons like the works of DeMarco, Yourdon, Parnas, Dijkstra, Hoare, Weinberg. 62
  63. 63. Language matterschoosing inappropriate metaphors, like craftsman, apprentice, journeyman, increasesgap between development and business.Software developers have their own definition of craftsmanship, but what matters isperception of customersAssociate craft with quality at a flea-market or craft fair - not something can reallyrely onhttp://www.flickr.com/photos/58289610@N00/3610407879/ 63
  64. 64. Terms "Master", "Journeyman", and "Apprentice“ bring up secretive guilds of middleages with ritual, mysticism, and intrigueSoftware craftsmen should be egoless, humble, with focus on outcome rather thancode or process 64
  65. 65. Manifesto brought people together and made it easier for them to roll out someideas on how to practice 65
  66. 66. Code katas - Dave Thomas from pragmatic programmersSmall problems to solveUncle Bob switched to practice on a solution insteadLike martial arts and how you repeat small motions and practice them until theybecome natural reflexesDo it over and over again until it becomes reflexKatacasts.com – Corey Haines has various screencasts known as katacast that showfolks practicing a small kata 66
  67. 67. Example Bowling Kata, Poker Kata, Supermarket Kata, Tennis KataPicture: http://www.flickr.com/photos/49715404@N00/3267627038/ 67
  68. 68. Code retreats started worldwideDevelopers get together on Saturday for full day of practiceWork on Conway’s game of life using technique “TDD as if you meant it”Focuses on TDD being all about evolutionary designPair-up, work on it for 45 minutes, then delete code, swap pairs and do it again 68
  69. 69. 2 companies swap employee for weekEmployees learn practices of another company and come back and try to improvetheir own environment 69
  70. 70. Craftsman journey – you go to company for 1 week and learn what they doInstead of going to conference, company will give you time off to go and work andlearn what others are doing 70
  71. 71. Craftsman spikes are side projects that you use to practice craftsmanshipCompanies offers employees 20% time to work on side projects 71
  72. 72. Software craftsmanship conferences established and 2 held each year, one in the UKand one in the USSeveral Software Craftsmanship User groups started 72
  73. 73. What does all this mean to you? 73
  74. 74. 74
  75. 75. 75
  76. 76. Contact Info 76
  77. 77. 77
  78. 78. 78
  79. 79. 79
  80. 80. 80
  81. 81. 81

×