Software Craftsmanship and Agile Code Games
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Software Craftsmanship and Agile Code Games

on

  • 848 views

Join us to talk about what it means to be a software craftsman, how the Software Craftsmanship Manifesto (http://manifesto.softwarecraftsmanship.org/) provides a framework for us to improve.

Join us to talk about what it means to be a software craftsman, how the Software Craftsmanship Manifesto (http://manifesto.softwarecraftsmanship.org/) provides a framework for us to improve.

A large part of being a software craftsman is practice. Using different "code games" we can have a full toolbelt of activities that will help us (and those around us) become better at our craft.

Agile software development promises the ability to deliver value quickly. But this isn’t just a matter of process. Uncle Bob says "the only way to go fast is to go well." But how do we go well? As software developers, we can only deliver features as fast as the code base and our skills allow us. Unfortunately the quality of our code base is directly related to our skill in the past.

Musicians and athletes spend most of their time practicing, not performing. As software developers (aspiring craftsmen) we must have practice sessions that allow us to improve our skills and develop better “code sense”. We’ll look at some different “agile code games” that will help us improve our craft.

Statistics

Views

Total Views
848
Views on SlideShare
529
Embed Views
319

Actions

Likes
1
Downloads
7
Comments
0

4 Embeds 319

http://www.agilecodegames.com 242
http://blog.softwareontheside.com 59
https://twitter.com 16
http://www.google.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Verbs vs. NounsRequirements“Plans are useless, but planning is invaluable” – Dwight D. Eisenhowerthe value is the process that everyone goes through in order to produce the document: the understanding gained, the relationships forged, the negotiations, the compromises, and all the other little interactions which share information.QualityPlan, measure, build a quality product!Quality is PART OF THE PROCESS. Quality is in the spirit of the smallest of our daily activities.
  • A Handbook for Agile Software Craftsmanship
  • March 2009A manifesto to complement the Agile Manifesto
  • Mostly about software testing, but great intro that talks about why code quality is important and uses the context of craftsmanship
  • Do any other professionals that use the title “engineer” work all the way through the process, from design to building to testing?So, while there are aspects of engineering in software, there is just as much craft.
  • Notes from recent discussion at the Salt Lake Agile Roundtable – question was “What’s different about Software Craftsmen? Why should a company care?”
  • Great for what it says, trying F#, but if you really want to learn how to use it, you need to use it in the environment in which you will use it for real.
  • Agile community has “Agile Games” that facilitate learning of agile/lean principlesEmily Bache talks about many of these as part of a catalog of activities that you would do at a Coding Dojo, but I wanted to broaden the scope.
  • Verbs vs. NounsRequirements“Plans are useless, but planning is invaluable” – Dwight D. Eisenhowerthe value is the process that everyone goes through in order to produce the document: the understanding gained, the relationships forged, the negotiations, the compromises, and all the other little interactions which share information.QualityPlan, measure, build a quality product!Quality is PART OF THE PROCESS. Quality is in the spirit of the smallest of our daily activities.
  • The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A".Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.htmlArt & Fear: Observations On the Perils (and Rewards) of Artmaking [Paperback]David Bayles (Author), Ted Orland (Author)We learn by DOING!I would argue that we can’t do quantity on the job. We have to get the volume of repetitions elsewhere.
  • Japanese word describing detailed choreographed patterns of movements practiced either solo or in pairs.A kata is a coding exercise that performed repeatedly and perfected.
  • Familiarity with TDDFamiliarity with Principles of Simple Design
  • if anyone is lost, pair should explain – audience can ask clarifying questions, but not give suggestions unless Green
  • A story, dialog, question or statement which is used to test a students progress.
  • Currently reading Apprenticeship Patterns
  • Verbs vs. NounsRequirements“Plans are useless, but planning is invaluable” – Dwight D. Eisenhowerthe value is the process that everyone goes through in order to produce the document: the understanding gained, the relationships forged, the negotiations, the compromises, and all the other little interactions which share information.QualityPlan, measure, build a quality product!Quality is PART OF THE PROCESS. Quality is in the spirit of the smallest of our daily activities.

Software Craftsmanship and Agile Code Games Presentation Transcript

  • 1. Software Craftsmanship and Agile Code Games Mike Clement @mdclement mike@softwareontheside.com http://blog.softwareontheside.com http://agilecodegames.com
  • 2. FAIR WARNING This is not a sit and listen session. This is an interactive session. You will be expected to code for most of the time with a pair.
  • 3. “Often the true value of a thing isn’t the thing itself, but instead is the activity that created it.” -Dave Thomas
  • 4. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
  • 5. Principles of Agile Software Development • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements, even late in development. • Deliver working software frequently. • Business people and developers must work together daily throughout the project. • Build projects around motivated individuals. • The most efficient and effective method of conveying information is face-to-face conversation. • Working software is the primary measure of progress. • Agile processes promote sustainable development. • Continuous attention to technical excellence and good design enhances agility. • Simplicity--the art of maximizing the amount of work not done--is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. • At regular intervals, the team reflects on how to become more effective, then adjusts accordingly.
  • 6. Literature Roots (1999 and 2001)
  • 7. Clean Code – August 2008
  • 8. Manifesto for Software Craftsmanship As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not only working software, but also well-crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
  • 9. Apprenticeship Patterns – October 2009
  • 10. The Clean Coder – May 2011
  • 11. Software Craftsmanship – 2013/2014
  • 12. Quality Code – November 2013
  • 13. Software Engineering? Engineering is the application of scientific, economic, social, and practical knowledge in order to design, build, maintain, and improve structures, machines, devices, systems, materials and processes. • Civil Engineers – do they drive rivets? • Automotive Engineers – do they assemble cars? • Computer Engineers – do they fabricate processors? • Software Engineers – do they write code?
  • 14. Craftsmanship: What’s different?
  • 15. “Going slow today to go fast tomorrow”
  • 16. “Going deliberately today to not be stuck tomorrow” – Me
  • 17. “The only way to go fast, is to go well” – Uncle Bob
  • 18. “Optimize for read time, not write time” – Me
  • 19. “maximizing the amount of work not done” – Agile Principles
  • 20. Things that Software Craftsmen Value • Growth mindset • Adapting and changing • Share over hoarding • Safety to experiment • Taking control of own destiny • Inclusiveness • Skill-centric over process-centric • Situated Learning
  • 21. Things that Software Craftsmen Value • Growth mindset • Adapting and changing • Share over hoarding • Safety to experiment • Taking control of own destiny • Inclusiveness • Skill-centric over process-centric • Situated learning
  • 22. Situated learning is learning that takes place in the same context in which it is applied.
  • 23. Agile Code Games How to learn without really trying
  • 24. “Often the true value of a thing isn’t the thing itself, but instead is the activity that created it.” -Dave Thomas
  • 25. Ceramics Quantity or Quality?
  • 26. Code Katas The scales and etudes of developing software
  • 27. Part of Guided Kata FizzBuzz
  • 28. Solo Randori Coding up a problem, probably repeatedly (sometimes referred to as a kata)
  • 29. Wasa Coding up a problem, with a pair
  • 30. Problem/Kata Lists • http://codingdojo.org/ • http://codekata.com/ • http://katas.softwarecraftsmanship.org/
  • 31. Group Randori Ready… fight!
  • 32. Quick Concepts TDD • Red • Green • Refactor Simple Design • Passes all tests • Clear, expressive, consistent • No duplication • Minimal
  • 33. Ways to get Green • Fake it • Obvious implementation • Triangulation
  • 34. Rules • Pair Programming • Use TDD • Everyone should be following • Pair should be explaining • Audience gives suggestions only with when Green • Today: Will switch pairs about every 2 minutes
  • 35. Numbers to LCD 123456789 Translates to: // _ _ _ _ _ _ _ // | _| _||_||_ |_ ||_||_| // ||_ _| | _||_| ||_| _|
  • 36. Koans The Path to Enlightenment
  • 37. Example Koans • http://rubykoans.com/ • https://github.com/ChrisMarinos/FSharpKoans • http://linqkoans.codeplex.com/
  • 38. Coderetreat A day like no other
  • 39. Structure of Coderetreat • Duration: 8:30am to 5 or 6pm (provide breakfast and lunch, not pizza) • Problem: Conway's Game of Life • Length of Session: 45 minutes (5 or 6 sessions usually) • Pair-programming is necessary, as the knowledge transfer contained in that activity is essential to the practice • Prefer using Test-Driven Development (TDD) • After each session, pairs should be swapped • After each session, code must be deleted, not put in a branch, not stashed, just deleted with no trace left
  • 40. Activities/Constraints • Explore the problem • Ping pong – intro to pairing techniques • No mouse • Paper only
  • 41. Activities/Constraints • No naked primitives • No conditionals • No loops • Only 2, 3, 4 lines per method • Immutable • Mute • Evil pair/find the loophole • Mute with find the loophole • Tell, don’t ask • TDD as if you meant it
  • 42. Mini-Coderetreat Session Code FizzBuzz with a pair but mute (no talking)
  • 43. Mob Programming Like Randori, but 15 minute switching cycles, and a real team working on a real system
  • 44. Utah Software Craftsmanship (UtahSC) Our meeting format differs from your usual technology user group. At a meeting we have: • 0-3 Lightning talks (up to but not over 5 minutes each) • ~30 min - Assigned Reading Discussion • ~60 min - Fellow Craftsman-run Coding Exercise (based on the principles of a Coding Dojo)
  • 45. “Often the true value of a thing isn’t the thing itself, but instead is the activity that created it.” -Dave Thomas
  • 46. Books • The Pragmatic Programmer: From Journeyman to Master • Clean Code • Apprenticeship Patterns (free online) • The Clean Coder • Software Craftsmanship: Professionalism, Pragmatism, Pride • Quality Code: Software Testing Principles, Practices, and Patterns • The Coding Dojo Handbook
  • 47. Resources • http://agilemanifesto.org/ • http://manifesto.softwarecraftsmanship.org/ • http://coderetreat.org/ • http://mobprogramming.org/ • http://www.agilecodegames.com/
  • 48. Mike Clement • @mdclement • mike@softwareontheside.com • http://blog.softwareontheside.com • http://agilecodegames.com • https://github.com/mdclement • Utah Software Craftsmanship • http://utahsc.org • @utahsc • We meet the first Wednesday at SLCC • http://agileroots.com