Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Software Craftsmanship: Paying Attention to Quality by Ken Auer

Software Craftsmanship: Paying Attention to Quality by Ken Auer

Some people seem to think that being a rock star programmer is about how many projects you participate in on github or how many follow you on twitter. But, the reality is that the quality of a Software Craftsman can be found in the work he produces. How do you get that quality up there, consistently keep it there, and keep raising the bar? Through a combination of some discussion on the nature of Skills Acquisition, and an analysis of common practices in software development (from Tests to Pull Requests to Pair Programming), we'll paint a picture of how to become a true expert.

About the Speaker:

Ken Auer was introduced as the father of Software Craftsmanship at the first Software Craftsmanship North America (SCNA) conference. Whether or not that is merited, he has always taken pride in his craft. He was one of the early pioneers of using Object-Oriented Programming in real world, commercial applications in the mid-80s, pioneered immersion-level apprentice programs in the early 90s, as well as Patterns, XP, and studio style development when he founded RoleModel Software in 1997. He believes that Software Craftsmen ship (rather than just blog and tweet about it), and lives to build high-performance teams that turn his clients' concepts into reality.

Triangle Ruby

December 10, 2013
Tweet

More Decks by Triangle Ruby

Other Decks in Programming

Transcript

  1. Phenomenon* 1. a fact or situation that is observed to

    exist or happen, esp. one whose cause or explanation is in question. * https://www.google.com/search?q=Phenomenon
  2. Community Participation* 1. Community Participation is a 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
  3. Craftsman* 1. a person who is skilled in a particular

    craft. synonyms: artisan, artist, skilled worker; expert, master * https://www.google.com/search?q=Craftsman+definition
  4. Wisdom* • “When there are 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)
  5. Object-Oriented Manifesto Everything is an Object 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”
  6. Patterns Manifesto “...to use patterns 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
  7. No More Manifestos* “I believe 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
  8. Two Points of Quality* • External (Business/Customer facing) • Correctness

    • Effectiveness • Internal (Technologist facing) • Software Asset leverage • Customer benefit: Maintainable/ Extendable... cost effectiveness * http://c2.com/cgi/wiki?InternalAndExternalQuality
  9. 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)
  10. 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
  11. Internal Facing Success • We are the SMEs of Quality

    Code • We are the Users • We need a model that works
  12. eXtreme Programming • code reviews => 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
  13. TDD, Refactoring, Pairing + Collective Code Ownership • Achieve validated

    quality code • Shared learning • In context • For context • Anyone(?) can keep it going forward with quality
  14. Reality of Internal Quality • 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 • 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
  15. Dreyfus Model of Skill 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/
  16. Knowledge vs. Skill* “There’s much 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/
  17. 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
  18. Learning in Context? “Situated Learning: 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
  19. Cost of Advanced Beginners Novice Advanced Beginner 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 Techniques Skills 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
  20. 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?
  21. High Performance Team in Custom Software Development Level Description Dreyfus

    Model plus experience Master Craftsman Sr. Craftsman Craftsman Expert >25,000 hours including >10,000 in leadership Expert/Proficient, >15,000 hours including >3,000 in leadership Proficient, typically >10,000 hours plus proven leadership skills Level Description Dreyfus Model plus experience Sr. Developer /Designer Developer /Designer Jr. Developer /Designer Competent to Proficient, >8,000 hours OR >6,000 hours plus leadership skills Competent, >5000 hours Competent w/ some holes in experience, >2000 hours Level Description Dreyfus Model plus experience Sr. Resident Developer/ Designer Resident Developer/ Designer Apprentice Developer/ Designer Novice Developer/ Designer Advanced Beginner with Competence in areas, Craftsmanship Academy >1500 hours Advanced Beginner with Competence in areas, Craftsmanship Academy >1000 hours Advanced Beginner, Craftsmanship Academy >500 hours Novice, in Craftsmanship Academy, <500 hours
  22. 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?
  23. Two Sets of Eyes 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”
  24. Two Sets of Eyes • 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 _____?”
  25. Effective Communication?* Github, StackOverflow Podcasts Destroy All Software, RailsCasts, ...

    * Graph taken from Alistair Cockburn, “Agile Software Development”, Addison-Wesley 2002 Books, Blogs
  26. Effective Skills Transfer Async Pull Requests Synchronous Pull Requests Pair

    Refactoring or Rewriting Opportunistic Pairing Pair Programming Code out Loud! Individual Code Deployed
  27. Acceptable Methods • Pair Programming • Opportunistic Pairing • Pair

    Refactoring/Rewriting • Synchronous pull requests • Asynchronous pull requests Hot High Skill Transfer Cold Low Skill Transfer
  28. Asynchronous Pull Requests • Code written by one person, reviewed

    later by someone else • Disadvantages • “Static” analysis - reading the diff & commenting... no review of thought process • “Missing Context” questions typically resolved through less rich communication • Advantages: Doesn’t break others FLOW, flex time
  29. Asynchronous Pull Requests Best Used When • Expected code quality

    is high • Common practices shared • Less challenging problems • Relatively small chunks of code • “Reasonable” turn-around of review
  30. Synchronous Pull Requests • Code written by one developer, reviewed

    later by someone else while dialoging with author... could be before or after commits • Disadvantages • “Static” analysis - reading the diff & reviewing latest thoughts • Need to coordinate time/presence... MIGHT break flow • Advantages: • “Missing Context” questions typically resolved through rich communication • Recommendations made through rich communication
  31. Synchronous Pull Requests Best Used When • Challenging problems tackled

    by one individual who needs to prove he can do it himself • Relatively small chunks of code • Too many problems/questions in async pull request... promote to synchronized review
  32. Pair Refactoring/Rewriting • Code already written by one developer, collaboratively

    improved with another • Disadvantages • “Static” analysis - reading the diff & reviewing latest thoughts • Need to coordinate time/presence... MIGHT break flow • Advantages: • “Missing Context” questions typically resolved through rich communication • Recommendations made through rich communication • Situated Learning by both parties
  33. Pair Refactoring/Rewriting Best Used When • One (or both) individual(s)

    lacks understanding of how to fix problems appropriately • Relatively small chunks of code • Too many problems/questions in async or sync pull request to effectively communicate otherwise
  34. Opportunistic Pairing • Two developers working on separate tasks of

    which both are knowledgeable... At any point, one calls the other in to pair • Disadvantages • Starting from latest thoughts of developer one • Need to coordinate time/presence... MIGHT break flow • Advantages: • “Missing Context” questions typically resolved through rich communication • Less rework • Situated Learning by both parties
  35. Opportunistic Pairing Best Used When • Clear that both parties

    have good handle on individual tasks • Part of problem may be non-trivial to at least one party • Second developer is close by, ready to help on short notice
  36. Pair Programming • Two developers working on single task •

    Disadvantages • Simple tasks that could easily be done by either party without help gets “help” anyway • Need to coordinate time/presence... interruptions to one party breaks pair flow • Advantages: • Context questions AND observations made through rich communication • Less rework • Situated Learning by both parties from beginning to end of task
  37. Pair Programming Best Used When • Problem is non-trivial to

    at least one party • Distractions are manageable for both parties • Shared culture & practices are not yet established • Learning is of higher importance than throughput • Critical/foundational parts of system
  38. Exceptions? • Short answer is “NEVER” • Real answer is

    “Rarely” and “Temporarily” • Fixing a production problem at night • Craftsman working by himself on least complex code • Prototype for demo
  39. What Do We Look For? • DRY code • Single

    (or appropriate) Responsibility • Intention Revealing names • Least amount of “state” possible • Tests (well-factored with reasonable edge cases) • Simple abstractions • Appropriate use of patterns • Consistent, readable structure • Appropriate use of 3rd party code (assets are liabilities) • Good OO practices • instances vs. globals • appropriate composition and inheritance • Follows appropriate idioms
  40. Other Rules of Thumb • 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
  41. Humble Yourself • You are 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