Downloaded 36 times
Uploaded byKen Auer
Software Craftsmanship: Agile Is Not Enough
The document discusses software craftsmanship, emphasizing that agile methodologies alone are insufficient for producing high-quality software. It highlights the importance of community participation, expert knowledge, and collaboration in software development, advocating for continuous refinement and feedback in coding practices. Key points include the need for both internal and external quality considerations and the Dreyfus model of skill acquisition to enhance expertise amongst developers.
Software Craftsmanship: Agile Is Not Enough
- 1. Software Craftsmanship: Agile isNot Enough Ken Auer @kauerrolemodel ken.auer@rolemodelsoftware.com
- 2. Phenomenon* 1.a fact orsituation that is observed to exist or happen, esp. one whose cause or explanation is in question. * https://www.google.com/search?q=Phenomenon
- 3. Community Participation* 1.Community Participation isa progressive political party in Colombia. At the last legislative elections, 10 March 2002, the party won, as one of the many small parties, parliamentary representation. In the election of 2006, the party won no seats. * https://www.google.com/search?q=Community%20participation%20definition
- 4. Craftsman* 1.a person whois skilled in a particular craft. synonyms: artisan, artist, skilled worker; expert, master * https://www.google.com/search?q=Craftsman+definition
- 5. Wisdom* • “When thereare many words, transgression is unavoidable, But he who restrains his lips is wise.” (Proverbs 10:19) • “For the dream comes through much effort and the voice of a fool through many words.” (Ecclesiastes 5:3) * All Scripture quotations taken from the New American Standard Bible®, Copyright © 1960, 1962, 1963, 1968, 1971, 1972, 1973, 1975, 1977, 1995 by The Lockman Foundation. Used by permission. (http://www.Lockman.org)
- 6.
- 7. Object-Oriented Manifesto Everything is anObject Send messages to them
- 8. Object-Oriented Manifesto Everything is anObject Send messages to them “Actually I made up the term object-oriented, and I can tell you I did not have C++ in mind.” Alan Kay 1997 OOPSLA Keynote “The Computer Revolution Hasn’t Happened Yet”
- 9. Patterns Manifesto “...to usepatterns in a generative way in the sense that Christopher Alexander uses patterns for urban planning and building architecture”* * http://hillside.net/home/history
- 10. Patterns Manifesto “...to usepatterns in a generative way in the sense that Christopher Alexander uses patterns for urban planning and building architecture”* * http://hillside.net/home/history “The Accused, by distilling hard-won design expertise into patterns, have encouraged novices to act like experts.” OOPSLA 1999 Show Trial of the Gang of Four
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17. * http://manifesto.softwarecraftsmanship.org GitHub &StackOverflow Participation ≠ Well-crafted Software
- 18.
- 19. No More Manifestos* “Ibelieve this new face of agility has three simple tenets, and doesn't need a manifesto at all: 1.Ship as often as possible. 2.Keep quality high. 3.Solicit and respond to feedback.” - David Starr, “So Long and Thanks for the All the Manifestos”,Visual Studio Magazine 16 June 2013 * http://visualstudiomagazine.com/articles/2013/06/01/so-long-and-thanks-for- the-all-the-manifestos.aspx
- 20. Two Points ofQuality* * http://c2.com/cgi/wiki?InternalAndExternalQuality
- 21. Two Points ofQuality* • External (Business/Customer facing) • Correctness • Effectiveness * http://c2.com/cgi/wiki?InternalAndExternalQuality
- 22. Two Points ofQuality* • External (Business/Customer facing) • Correctness • Effectiveness • Internal (Technologist facing) • Software Asset leverage • Customer benefit: Maintainable/Extendable... cost effectiveness * http://c2.com/cgi/wiki?InternalAndExternalQuality
- 23.
- 24. Dartboards & Darts •Every project • Identify dartboard(s) • Identify interested dart player(s) • Build capable dart(s)
- 25. Dartboards & Darts •Every project • Identify dartboard(s) • Identify interested dart player(s) • Build capable dart(s) Scenario(s)
- 26. Dartboards & Darts •Every project • Identify dartboard(s) • Identify interested dart player(s) • Build capable dart(s) Scenario(s) Persona(s)
- 27. Dartboards & Darts •Every project • Identify dartboard(s) • Identify interested dart player(s) • Build capable dart(s) Scenario(s) Persona(s) Software Asset(s)
- 28. Dartboards & Darts •Every project • Identify dartboard(s) • Identify interested dart player(s) • Build capable dart(s) • Validate and repeat until you have a winning combination... Scenario(s) Persona(s) Software Asset(s)
- 29. Dartboards & Darts •Every project • Identify dartboard(s) • Identify interested dart player(s) • Build capable dart(s) • Validate and repeat until you have a winning combination... • ...or the money runs out Scenario(s) Persona(s) Software Asset(s)
- 30.
- 31. Business Facing Success •Need a Subject Matter Expert (SME) to identify potentially viable dartboards • a dedicated SME or • someone dedicated to becoming a SME
- 32. Business Facing Success •Need a Subject Matter Expert (SME) to identify potentially viable dartboards • a dedicated SME or • someone dedicated to becoming a SME • Need User Feedback • access to Users (various roles/personas) • access to Potential Users
- 33. Business Facing Success •Need a Subject Matter Expert (SME) to identify potentially viable dartboards • a dedicated SME or • someone dedicated to becoming a SME • Need User Feedback • access to Users (various roles/personas) • access to Potential Users • A business model that works with the above
- 34.
- 35. Internal Facing Success •We are the SMEs of Quality Code
- 36. Internal Facing Success •We are the SMEs of Quality Code • We are the Users
- 37. Internal Facing Success •We are the SMEs of Quality Code • We are the Users • We need a model that works
- 38. Subject Matter Experts? What isan Expert?
- 39.
- 40.
- 41. Continuous Refinement of... •Requirements • Design • Plan • People • Results Potential Value! ?
- 42. eXtreme Programming • codereviews => pair programming • testing => 100% unit, tracking acceptance • design => continuous refactoring • simplicity => TSTTCPW, YAGNI, test-driven • customer involvement => they drive • integration => daily or more often • short iterations => 1-4 week release cycle • risk management => collective code ownership
- 43. TDD, Refactoring, Pairing+ Collective Code Ownership
- 44. TDD, Refactoring, Pairing+ Collective Code Ownership • Achieve validated quality code
- 45. TDD, Refactoring, Pairing+ Collective Code Ownership • Achieve validated quality code • Shared learning
- 46. TDD, Refactoring, Pairing+ Collective Code Ownership • Achieve validated quality code • Shared learning • In context
- 47. TDD, Refactoring, Pairing+ Collective Code Ownership • Achieve validated quality code • Shared learning • In context • For context
- 48. TDD, Refactoring, Pairing+ Collective Code Ownership • Achieve validated quality code • Shared learning • In context • For context • Anyone(?) can keep it going forward with quality
- 49. Reality of InternalQuality
- 50. Reality of InternalQuality • Easy for anyone to slip in the name of expediency
- 51. Reality of InternalQuality • Easy for anyone to slip in the name of expediency • Make it run. Make it right. Make it fast. OR
- 52. Reality of InternalQuality • Easy for anyone to slip in the name of expediency • Make it run. Make it right. Make it fast. OR • Make it run... fast enough?… Ship it.
- 53. Reality of InternalQuality • Easy for anyone to slip in the name of expediency • Make it run. Make it right. Make it fast. OR • Make it run... fast enough?… Ship it. • Make it right?
- 54. Reality of InternalQuality • Easy for anyone to slip in the name of expediency • Make it run. Make it right. Make it fast. OR • Make it run... fast enough?… Ship it. • Make it right? • Limited by expertise of most skilled participant
- 55. Reality of InternalQuality • Easy for anyone to slip in the name of expediency • Make it run. Make it right. Make it fast. OR • Make it run... fast enough?… Ship it. • Make it right? • Limited by expertise of most skilled participant • Can increase by collaboration
- 56. Reality of InternalQuality • Easy for anyone to slip in the name of expediency • Make it run. Make it right. Make it fast. OR • Make it run... fast enough?… Ship it. • Make it right? • Limited by expertise of most skilled participant • Can increase by collaboration • Two novices don’t produce the quality of experts by pairing
- 57. Reality of InternalQuality • Easy for anyone to slip in the name of expediency • Make it run. Make it right. Make it fast. OR • Make it run... fast enough?… Ship it. • Make it right? • Limited by expertise of most skilled participant • Can increase by collaboration • Two novices don’t produce the quality of experts by pairing
- 58. Dreyfus Model ofSkill Acquisition* Rules Detached Observer Considers Everything Intuition Relevant Focus Part of System Novice Advanced Beginner Competent Proficient Expert * http://litemind.com/expert-roadmap/
- 59. Dreyfus Model ofSkill Acquisition* Rules Detached Observer Considers Everything Intuition Relevant Focus Part of System Novice Advanced Beginner Competent Proficient Expert Context Matters * http://litemind.com/expert-roadmap/
- 60. Knowledge vs. Skill* “There’smuch more to mastering a skill than just acquiring more knowledge. Just like adults are not simply bigger children, experts are not only smarter, more knowledgeable or faster than novices.The differences can be found at a more fundamental level, such as in how they perceive the world and approach problems.” - Luciano Passuello * http://litemind.com/expert-roadmap/
- 61. To a Novice,an Advanced Beginner looks like an Expert “Have cheap people do easy things under the CLOSE supervision of someone who knows the difference” - Me, 2010 SCNA talk “Lean Craftsmanship vs. Corporate Craftsmanship” “Have advanced beginners do tasks for which the rules they know are appropriate to the context and check their work. Let them watch, and have discussions with, someone who has the appropriate skills for the task when the advanced beginner does not” - Me,Today, this talk
- 62.
- 63. Learning in Context? “TheReligious Tradesman” - Richard Steele Excellent thoughts on business Section on apprenticeship
- 64. Learning in Context? “SituatedLearning: Legitimate Peripheral Participation” - Jean Lave & Etienne Wenger People learn by being there Not out of sight of experts work “The Religious Tradesman” - Richard Steele Excellent thoughts on business Section on apprenticeship
- 65. Cost of Advanced Beginners Novice AdvancedBeginner Competent Proficient Expert Clueless Mostly “right” Make it run... right? All of us are Novices at some things... Some may be experts in others... Usually somewhere in between Tools TechniquesSkills Domains Languages
- 66. Cost of Advanced Beginners Novice AdvancedBeginner Competent Proficient Expert Clueless Mostly “right” Make it run... right? All of us are Novices at some things... Some may be experts in others... Usually somewhere in between Tools TechniquesSkills Domains Languages Follow rules on well-defined tasks
- 67. Cost of Advanced Beginners Novice AdvancedBeginner Competent Proficient Expert Clueless Mostly “right” Make it run... right? All of us are Novices at some things... Some may be experts in others... Usually somewhere in between Tools TechniquesSkills Domains Languages Follow rules on well-defined tasks Complete similar tasks following rules
- 68. Cost of Advanced Beginners Novice AdvancedBeginner Competent Proficient Expert Clueless Mostly “right” Make it run... right? All of us are Novices at some things... Some may be experts in others... Usually somewhere in between Tools TechniquesSkills Domains Languages Follow rules on well-defined tasks Complete similar tasks following rules Have conceptual models in which to operate
- 69. Cost of Advanced Beginners Novice AdvancedBeginner Competent Proficient Expert Clueless Mostly “right” Make it run... right? All of us are Novices at some things... Some may be experts in others... Usually somewhere in between Tools TechniquesSkills Domains Languages Follow rules on well-defined tasks Complete similar tasks following rules Have conceptual models in which to operate Have conceptual framework in which to adjust
- 70. Cost of Advanced Beginners Novice AdvancedBeginner Competent Proficient Expert Clueless Mostly “right” Make it run... right? All of us are Novices at some things... Some may be experts in others... Usually somewhere in between Tools TechniquesSkills Domains Languages Follow rules on well-defined tasks Complete similar tasks following rules Have conceptual models in which to operate Have conceptual framework in which to adjust Intuitively identify and solve problems... it’s simple
- 71. Getting Past Advanced Beginner •“Proficient practitioners can take full advantage of the reflection and feedback that is core to agile methods.” – (“Pragmatic Thinking & Learning”, Andrew Hunt, p.35) • But how do you get there? – Individual exercise? – Team work?
- 72. High Performance Teamin Custom Software Development Level Description Dreyfus Model plus experience Master Craftsman Expert >25,000 hours including >10,000 in leadership Sr. Craftsman Expert/Proficient, >15,000 hours including >3,000 in leadership Craftsman Proficient, typically >10,000 hours plus proven leadership skills
- 73. High Performance Teamin Custom Software Development Level Description Dreyfus Model plus experience Master Craftsman Expert >25,000 hours including >10,000 in leadership Sr. Craftsman Expert/Proficient, >15,000 hours including >3,000 in leadership Craftsman Proficient, typically >10,000 hours plus proven leadership skills Level Description Dreyfus Model plus experience Sr. Developer /Designer Competent to Proficient, >8,000 hours OR >6,000 hours plus leadership skills Developer /Designer Competent, >5000 hours Jr. Developer /Designer Competent w/ some holes in experience, >2000 hours
- 74. High Performance Teamin Custom Software Development Level Description Dreyfus Model plus experience Master Craftsman Expert >25,000 hours including >10,000 in leadership Sr. Craftsman Expert/Proficient, >15,000 hours including >3,000 in leadership Craftsman Proficient, typically >10,000 hours plus proven leadership skills Level Description Dreyfus Model plus experience Sr. Developer /Designer Competent to Proficient, >8,000 hours OR >6,000 hours plus leadership skills Developer /Designer Competent, >5000 hours Jr. Developer /Designer Competent w/ some holes in experience, >2000 hours Level Description Dreyfus Model plus experience Sr. Resident Developer/ Designer Advanced Beginner with Competence in areas, Craftsmanship Academy >1500 hours Resident Developer/ Designer Advanced Beginner with Competence in areas, Craftsmanship Academy >1000 hours Apprentice Developer/ Designer Advanced Beginner, Craftsmanship Academy >500 hours Novice Developer/ Designer Novice, in Craftsmanship Academy, <500 hours
- 75.
- 76. RoleModel Internal Quality Goals •Proficient level code is the minimum acceptable
- 77. RoleModel Internal Quality Goals •Proficient level code is the minimum acceptable • Craftsman level code is the goal
- 78. RoleModel Internal Quality Goals •Proficient level code is the minimum acceptable • Craftsman level code is the goal • But how do we keep it at that level when others are on the project?
- 79. Two Sets ofEyes on all production code The RoleModel Standard for Internal Quality... A reminder that we care about “Make it Right” AND “Helping Others Learn the Craft”
- 80. Two Sets ofEyes
- 81. Two Sets ofEyes • In a project
- 82. Two Sets ofEyes • In a project • Craftsmanship level will rarely be achieved without a Craftsman
- 83. Two Sets ofEyes • In a project • Craftsmanship level will rarely be achieved without a Craftsman • Typically, will only rise to “Highest Skill Level” on the project
- 84. Two Sets ofEyes • In a project • Craftsmanship level will rarely be achieved without a Craftsman • Typically, will only rise to “Highest Skill Level” on the project • Across projects
- 85. Two Sets ofEyes • In a project • Craftsmanship level will rarely be achieved without a Craftsman • Typically, will only rise to “Highest Skill Level” on the project • Across projects • Can benefit from Higher Skill Level input
- 86. Two Sets ofEyes • In a project • Craftsmanship level will rarely be achieved without a Craftsman • Typically, will only rise to “Highest Skill Level” on the project • Across projects • Can benefit from Higher Skill Level input • “How did/would you do _______ in the context of _____?”
- 87. Effective Communication?* * Graphtaken from Alistair Cockburn,“Agile Software Development”,Addison-Wesley 2002
- 88. Effective Communication?* Github, StackOverflow Podcast Destroy AllSoftware, RailsCasts, ... * Graph taken from Alistair Cockburn,“Agile Software Development”,Addison-Wesley 2002
- 89. Effective Communication?* Github, StackOverflow Podcast Destroy AllSoftware, RailsCasts, ... * Graph taken from Alistair Cockburn,“Agile Software Development”,Addison-Wesley 2002 Books, Blogs
- 90.
- 91. Effective Skills Transfer AsyncPull Requests
- 92. Effective Skills Transfer AsyncPull Requests Synchronous Pull Requests
- 93. Effective Skills Transfer AsyncPull Requests Synchronous Pull Requests Pair Refactoring or Rewriting
- 94. Effective Skills Transfer AsyncPull Requests Synchronous Pull Requests Pair Refactoring or Rewriting Opportunistic Pairing
- 95. Effective Skills Transfer AsyncPull Requests Synchronous Pull Requests Pair Refactoring or Rewriting Opportunistic Pairing Pair Programming
- 96. Effective Skills Transfer AsyncPull Requests Synchronous Pull Requests Pair Refactoring or Rewriting Opportunistic Pairing Pair Programming Code outLoud!
- 97. Effective Skills Transfer AsyncPull Requests Synchronous Pull Requests Pair Refactoring or Rewriting Opportunistic Pairing Pair Programming Code outLoud! Individual Code Deployed
- 98. Acceptable Methods • PairProgramming • Opportunistic Pairing • Pair Refactoring/Rewriting • Synchronous pull requests • Asynchronous pull requests Hot High Skill Transfer Cold Low Skill Transfer
- 99.
- 100. Exceptions? • Short answeris “NEVER”
- 101. Exceptions? • Short answeris “NEVER” • Real answer is “Rarely” and “Temporarily” • Fixing a production problem at night • Craftsman working by himself on least complex code • Prototype for demo
- 102. What Do WeLook For? • Intention Revealing names • DRY code • Single (or appropriate) Responsibility • Least amount of “state” possible • Tests (well-factored with reasonable edge cases) • Simple abstractions • Appropriate use of patterns • Consistent, readable structure • Good OO practices • instances vs. globals • appropriate composition and inheritance • Follows appropriate idioms • Appropriate use of 3rd party code (assets are liabilities)
- 103. Other Rules ofThumb
- 104. Other Rules ofThumb • Don’t use the same reviewer all the time
- 105. Other Rules ofThumb • Don’t use the same reviewer all the time • Cross projects when possible/ reasonable
- 106. Other Rules ofThumb • Don’t use the same reviewer all the time • Cross projects when possible/ reasonable • Goal is to raise the bar, not to win an argument • Thick skin • Tender heart
- 107. Humble Yourself • Youare probably somewhere between a Novice and Proficient in most things you do • Find someone better (or potentially better) than you • Find someone who can learn from you • If you are an expert, find something else to do that takes you out of your comfortable context(s) • Don’t stop reading, but seek more collaboration • If you work alone, collaborate more often • Encourage others to raise the bar
- 108. Are You anAspiring Software Craftsman? • Our Craftsmanship Academy is one way • next entrance in June • Immersion Phase - 14-16 weeks - foundation laid and reinforced • Apprenticeship follows • But… * http://craftsmanshipacademy.com
- 109. Take Charge • Youhave work to do • Do it well • No one is stopping you • Ask your boss, “do you want us to get better at software development, or just get better at stand-up meetings”?
- 110.
- 111.
- 112. Dreyfus Model References • http://en.wikipedia.org/wiki/ Dreyfus_model_of_skill_acquisition • http://1.usa.gov/1iOLuWC - Dreyfus, Stuart E.; Dreyfus, Hubert L. (February 1980), A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition • http://bit.ly/1fU3aLn - Benner, Patricia (2004), Using the Dreyfus Model of Skill Acquisition to Describe and Interpret Skill Acquisition and Clinical Judgment in Nursing Practice and Education