![[LARM03]](https://image.slidesharecdn.com/you-cant-be-agile-if-your-code-sucks-v0-131203150417-phpapp01/75/You-cant-be-agile-if-your-code-sucks-28-2048.jpg)
Uploaded byPeter Gfader
You cant be agile if your code sucks
The document discusses the principles of agile development, emphasizing the importance of software craftsmanship and continuous improvement over rigid processes. It critiques common pitfalls in coding practices, such as writing bad code, and promotes practices like code reviews and test-driven development to achieve better quality software. The author encourages a mindset of experimentation and collaboration within development teams to enhance both the coding process and the final product.
More Related Content
Similar to You cant be agile if your code sucks
You cant be agile if your code sucks
- 1. You can’t beAgile if your code sucks Peter Gfader twitter.com/peitor
- 2. My Mission #1 Agile?? #2Code & Craftmanship
- 3.
- 4.
- 5.
- 6. What is Agilefor you?
- 7.
- 10. The Agile Manifestoinvites wimpy-ness "… Individuals and interactions over processes & tools…" Yayy!! I don't have to follow those stupid processes any more! "… Working software over comprehensive documentation…" W00t!! Dump the documentation! I LOVE this agile stuff! "… Customer collaboration over contract negotiations…" I'm done when I'm done and I never have to say when! "… Responding to change over following a plan…" No plans! No project managers! No architects! Where do I sign up? © Alistair Cockburn
- 11. What is Agilefor you?
- 12. What is allthis stuff? XP Lean RUP SAFe Agile © Henrik Knieberg
- 13. Thinking tools Tool a.k.a. ”mindsets”or ”philosophies” ”anything used as a means of accomplishing a task or purpose.” - dictionary.com Physical tools Lean Agile Systems Thinking Theory of Constraints Toolkits a.k.a. ”frameworks” Scrum RUP XP Kanban Process tools a.k.a. ”organizational patterns” Product Owner role Pair programming Visualize the workflow 5 Dev 3 H Test Release D To do C 2 G 3 Done! A B K FLOW © Henrik Knieberg
- 14.
- 15. The illusion ofa ”bad tool” The old tool was better! Don’t blame the tool! © Henrik Knieberg
- 16. Compare for understanding, not judgement Key point ©Henrik Knieberg
- 17. Compare for understanding, not judgement Key point Toolscan be combined © Henrik Knieberg
- 18. • Know yourGoal Take-away points o Why • Agile/Lean are tools, not goals • Don’t limit yourself to one tool • Experiment & enjoy the ride o Don’t worry about getting it right from start © Henrik Knieberg • We won’t
- 19.
- 20. The important thingisn’t the process. © Henrik Knieberg
- 21. The important thingisn’t the process. The important thing is the process for improving your process. © Henrik Knieberg
- 22. The important thingisn’t the process. The important thing is the process for improving your process. Continuous Improvement © Henrik Knieberg
- 23. 3 essential skillsneeded regardless of process Splitting the system into useful pieces Software craftsmanship Retrospectives As a buyer I want to save my shopping cart so that I can continue shopping later © Henrik Knieberg
- 24. 3 essential skillsneeded regardless of process Splitting the system into useful pieces As a buyer I want to save my shopping cart so that I can continue shopping later Software craftsmanship Retrospectives
- 25. 3 essential skillsneeded regardless of process Splitting the system into useful pieces As a buyer I want to save my shopping cart so that I can continue shopping later Software craftsmanship Retrospectives
- 26.
- 27. 1) Software isnever written once and never changed
- 28.
- 29. 2) How toslow down your project?
- 32. Write crappy code Make code easier to read
- 33. Easy code toread Easy code to change maintain
- 34. Why do youwrite bad code?
- 35. #1 reason forBad code We write bad code, because we read bad code
- 36. Code Readings? • • • • Code Reviews PeerReviews Pair Programming Open source
- 37. Good code islike a joke! No need for explanation
- 38. #TODO: Code toread https://github.com/nsubstitute/NSubstitute https://github.com/techtalk/SpecFlow https://github.com/sf105/goos-code https://github.com/machine/machine.specifications https://github.com/BjRo/xunitbddextensions https://github.com/dtchepak/DaveSquared.StringsTheThing
- 39. #TODO: Review Code • • • • Inyour team With 1 peer Open source Brown bags – Lunch time discussion
- 40. Code Reviews • Code,!Person • Constructively propose changes Questions!
- 41. Code Reviews • Code,!Person • Constructively propose changes Questions! • Review not only code o Tests o Build process o ..
- 42. Code Reviews • Code,!Person • Constructively propose changes Questions! • Review not only code o Tests o Build process o .. Grow as a team
- 43. Instead of “That lousylong method” Say “Why don’t you split that method” “I reviewed your code and found 1,2,3 things to change” “Can you help me?” “If you don’t want to do it. I do it” “Can I help you with this? I think we can improve it”
- 44. #2 reason forBad code Nobody can write good code in 1 sit-in -> Refactoring it’s an art of designing code
- 45.
- 46. The little issuewith Refactoring?
- 47. Development With andWithout Testing Without Tests • Don’t know our own quality • Unclear what works and what doesn't • Unintended consequences of changes remain hidden • We are never done With Tests • Change and refactor without fear • Add new features faster • Confidence that we didn't break anything • We can actually be done Done = Tested!
- 48.
- 49.
- 50. Test-Driven Development (TDD) •Writing tests prior to writing the production code • Test-Driven Development is o o o o A design practice A powerful way to avoid defects in software A feedback loop for validating code changes A way to write tests REFACTOR RED GREEN
- 51. Test-Driven Development (TDD) Goalis not to write tests but to write good code RED REFACTOR GREEN
- 52.
- 53. “Why should Icare? We have a QA department!”
- 54. **** ADD PIC****
- 55. How do youmeasure Quality?
- 57. First Law ofProgramming “Lowering Quality Lengthens Development Time” http://c2.com/cgi/wiki?FirstLawOfProgramming
- 58. Only Quality letsus go faster!
- 59.
- 60.
- 61. Quality? • Measure ofhow well the software is designed and implemented • Subjective
- 62. Quality? • • • • • • LOC Code Coverage Class Coupling Cohesion CodeDuplication Cyclomatic Complexity
- 63. Quality: How tomeasure? • • • • • • • Highly subjective Highly qualitative Is the code readable, understandable? Is the code verbose? Variable/method names that are meaningful Simple code that works Does it have tests? What’s the coverage?
- 64. Quality: How tomeasure? • Trends
- 65. Quality: How tomeasure? • Trends • “Output” over time o Velocity - Trend o Business Value - Trend o Bug – Trends • #TODO: How do you measure Business value?
- 66. Ways to ImproveQuality • Avoid Silo Thinking o • • • • • • • Its not “us” vs “them” Start early Don’t Compromise Schedule time to lower your technical debt Make it work; make it right (right away) Requires monitoring and changing behavior Be willing to help and be helped Devise lightweight non-bureaucratic measures
- 67. Simple Design ==High Quality? • • • • Passes its tests Minimizes duplication Maximizes clarity Has fewer elements http://c2.com/cgi/wiki?XpSimplicityRules
- 68. #TODO Visualize • • • • • Bug Trends BuildStatus Performance Report Technical Debt Code Quality
- 69.
- 70.
- 71. Checkin Frequently • Focusyour work on small tasks • Easier to describe what you did in your check-in comment • Clear code history • Easier merging -> if you really need to branch and merge • Fast code reviews • Never get merge hell -> only give it :-) http://blog.gfader.com/2011/12/tfs-see-your-application-grow-like.html
- 72. Team Efforts • AvoidShortcuts • Take collective ownership Team should own the code • Promote positive interaction • Provide constructive feedback • Constant code review
- 73. Guantanamo Code Tool •All code is guilty until tested innocent • Do you have problems maintaining high test coverage? • Send the untested code to Guantanamo! http://docs.codehaus.org/display/ASH/Guantanamo
- 74. Agile – thebar is rising http://blog.gfader.com/2013/05/the-1st-principle-of-agile-manifesto-30.html
- 75. Our highest priorityis to satisfy the customer through early and continuous delivery of valuable software 1st principle of the Agile Manifesto
- 76. Our highest priorityis to satisfy the customer through early and continuous delivery of valuable software 1st principle of the Agile Manifesto
- 77.
- 78. The important thingisn’t the process The important thing is the process for improving your process
- 79. Essential skills needed regardlessof process Splitting the system into useful pieces As a buyer I want to save my shopping cart so that I can continue shopping later Software craftsmanship Retrospectives
- 80. #TODO TO READ E.Goldratt “The Goal” S.Freeman, N.Price GOOS
- 81. #TODO References • • • • • • • Pragmatics ofAgile Development http://www.agiledeveloper.com/presentations/pragmatics_of_agile_development.pdf Kanban VS Scrum http://www.infoq.com/minibooks/kanban-scrum-minibook Agile Software Development http://www.agiledeveloper.com/presentations/AgileSoftwareDevelopment.zip A Thinking Tool called Agile https://sites.google.com/site/leanagileandscrum/lean-agile-scrum-conference2010/presentations-las-2010/00_Kniberg_Keynote.pdf?attredirects=0&d=1 The Four Elements of Simple Design http://www.jbrains.ca/permalink/the-four-elements-of-simple-design http://agilemanifesto.org/ http://manifesto.softwarecraftsmanship.org/
- 82. Now you 1. 2. 3. 4. Download presentation Searchfor #TODO Get it done Send me a tweet “I’m done”
- 83.
Editor's Notes
- #2 Click to add notesPeter Gfader
- #3 3 ingredients for success
- #4 Wiekommeichzu Agile?1. Scrum/AgileSüdtirolProjekte: Alles gut -> ZumSchluss (Graph from xscd)Graph: Happiness, Definition Wahnsinn: Immerwieder das Gleichemacht, abereinanderesErgebniserwartet2. AgileMinimize Risk: Deployment dayFertigmitEntwickeln. Deploy -> Hardware ist da, OS und tools alles da. Deploy to Production.Funzt net. **TODO: Find the problem we had @AuctionsPlus, @POK, POK: IP filtering, ...
- #5 Wiekommeichzu Scrum und CD?1. Scrum/AgileSüdtirolProjekte: Alles gut -> ZumSchluss (Graph from xscd)Graph: Happiness, Definition Wahnsinn: Immerwieder das Gleichemacht, abereinanderesErgebniserwartet2. AgileMinimize Risk: Deployment dayFertigmitEntwickeln. Deploy -> Hardware ist da, OS und tools alles da. Deploy to Production.Funzt net. **TODO: Find the problem we had @AuctionsPlus, @POK, POK: IP filtering, ...
- #7 Develop relevant softwareDeliver value earlierCreate value fastWelcome changes and gapsOpen communicationEmpowering peopleKeep it simple
- #10 2011 Snowbird
- #12 Develop relevant softwareDeliver value earlierCreate value fastWelcome changes and gapsOpen communicationEmpowering peopleKeep it simple
- #13 Purpose of this presentation is to clarify how some of these things fit togetherHow does agile look when done well?
- #15 Pretty meaningless question right? Because the answer depends on your context. For eating meatballs the fork is probably best. For chopping mushrooms the knife is probably best. For drumming on the table either will do fine. For eating a steak you probably want to use both tools together. For eating rice... well... some prefer fork while others prefer chopsticks.
- #16 Never blame the tool!
- #17 Vergleichen um zuVerstehen und Lernen und nichtBeurteilen und Schlechtmachen
- #18 Vergleichen um zuVerstehen und Lernen und nichtBeurteilen und Schlechtmachen
- #19 Don’t love agile.Know your GoalFocus on WhyAgile/Lean are tools, not goalsTools sind nicht erfolgreich oder scheitern. Menschen sind aber.Es gibt kein gutes oder schlechtes Tool. Nur gute oder Schlechte Entscheidungen wenn, wo, wie und wieso wir ein Tool einsetzenDon’t limit yourself to one toolMix & matchCompare for understanding, not judgement.Experiment & enjoy the rideDon’t worry about getting it right from start. You won’t.The important thing isn’t your process.The important thing is your process for improving your process.
- #20 Purpose of this presentation is to clarify how some of these things fit togetherHow does agile look when done well?
- #26 - Communication Skills- Facilitator / ScrumMaster- Vision
- #48 Having good tests is like have great brakes on a sports car. Good brakes allow us to go faster.We do not know the QualityFearless refactoring requires Tests. Refactoring is required to react on a changing worldWe are faster releasing the SWDone = Tested. No DoneDone!
- #49 waste?
- #51 Sometimes you don’t need well designed codeGoal is not to write tests but to write good code
- #52 Sometimes you don’t need well designed codeGoal is not to write tests but to write good code
- #54 Tester
- #61 Go fast -> Go well
- #63 Cyclomatic Complexity NumberGives an indication of degree of hardnessDoes not indicate degree of defectAddresses problems arising from large, low cohesive codeCode Size Rules check for the size of code and flags if it exceedsHow small is smallCode must fit into a screen (without lowering font size)[about 15 to 20 statements per method]