You can’t be Agile
if your code sucks

Peter Gfader
twitter.com/peitor
My Mission
#1 Agile??
#2 Code & Craftmanship
About me
Peter Gfader

peter.gfader@zuehlke.com
http://blog.gfader.com
twitter.com/peitor
Agile
What is Agile for you?
http://agilemanifesto.org/
The Agile Manifesto invites wimpy-ness
"… Individuals and interactions over processes & tools…"
Yayy!! I don't have to fol...
What is Agile for you?
What is all this stuff?

XP
Lean

RUP

SAFe

Agile
© Henrik Knieberg
Thinking tools

Tool

a.k.a. ”mindsets” or ”philosophies”

”anything used as a means of
accomplishing a task or purpose.”
...
© Henrik Knieberg
The illusion of a ”bad tool”

The old
tool
was
better!
Don’t blame
the tool!

© Henrik Knieberg
Compare for
understanding, not
judgement

Key
point

© Henrik Knieberg
Compare for
understanding, not
judgement

Key
point

Tools can be
combined
© Henrik Knieberg
• Know your Goal

Take-away points

o Why

• Agile/Lean are tools, not goals
• Don’t limit yourself to one tool
• Experime...
RUP

XP
Lean

SAFe

Agile
© Henrik Knieberg
The important thing isn’t the process.

© Henrik Knieberg
The important thing isn’t the process.

The important thing is the process for
improving your process.

© Henrik Knieberg
The important thing isn’t the process.

The important thing is the process for
improving your process.

Continuous Improve...
3 essential skills needed
regardless of process

Splitting the system into
useful pieces

Software
craftsmanship

Retrospe...
3 essential skills needed
regardless of process

Splitting the system into
useful pieces

As a buyer
I want to save my sho...
3 essential skills needed
regardless of process

Splitting the system into
useful pieces

As a buyer
I want to save my sho...
Essential Skill:
Software craftsmanship
1) Software is never written
once and never changed
[LARM03]
2) How to slow down your
project?
Write crappy code
 Make code easier to read
Easy code to read
 Easy code to change
maintain
Why do you write bad code?
#1 reason for Bad code
We write bad code,
because we read bad code
Code Readings?
•
•
•
•

Code Reviews
Peer Reviews
Pair Programming
Open source
Good code is like a joke!
No need for explanation
#TODO: Code to read
https://github.com/nsubstitute/NSubstitute
https://github.com/techtalk/SpecFlow
https://github.com/sf1...
#TODO: Review Code
•
•
•
•

In your team
With 1 peer
Open source
Brown bags – Lunch time discussion
Code Reviews
• Code, !Person
• Constructively propose changes
 Questions!
Code Reviews
• Code, !Person
• Constructively propose changes
 Questions!

• Review not only code
o Tests
o Build process...
Code Reviews
• Code, !Person
• Constructively propose changes
 Questions!

• Review not only code
o Tests
o Build process...
Instead of
“That lousy long method”

Say
“Why don’t you split that
method”

“I reviewed your code and
found 1,2,3 things t...
#2 reason for Bad code
Nobody can write good code in 1 sit-in

-> Refactoring
it’s an art of designing code
#TODO Refactoring
https://github.com/NotMyself/GildedRose
https://github.com/jcbozonier/Refactoring-Katas
The little issue with
Refactoring?
Development With and Without Testing
Without Tests

• Don’t know our own quality
• Unclear what works and what
doesn't
• U...
Refactoring
+
Tests
=
?
Refactoring
+
Tests
=
Waste?? Overhead??
Test-Driven Development (TDD)
• Writing tests prior to writing the production code
• Test-Driven Development is
o
o
o
o

A...
Test-Driven Development (TDD)
Goal is not to write tests
but to write good code

RED

REFACTOR

GREEN
What is Quality
“Why should I care?
We have a QA department!”
**** ADD PIC ****
How do you measure
Quality?
First Law of Programming

“Lowering Quality Lengthens
Development Time”
http://c2.com/cgi/wiki?FirstLawOfProgramming
Only Quality lets us go faster!
http://manifesto.softwarecraftsmanship.org/
Who?
Quality?
• Measure of how well the software is
designed and implemented
• Subjective
Quality?
•
•
•
•
•
•

LOC
Code Coverage
Class Coupling
Cohesion
Code Duplication
Cyclomatic Complexity
Quality: How to measure?
•
•
•
•
•
•
•

Highly subjective
Highly qualitative
Is the code readable, understandable?
Is the ...
Quality: How to measure?
• Trends
Quality: How to measure?
• Trends
• “Output” over time
o Velocity - Trend
o Business Value - Trend
o Bug – Trends

• #TODO...
Ways to Improve Quality
• Avoid Silo Thinking
o

•
•
•
•
•
•
•

Its not “us” vs “them”

Start early
Don’t Compromise
Sched...
Simple Design == High Quality?
•
•
•
•

Passes its tests
Minimizes duplication
Maximizes clarity
Has fewer elements
http:/...
#TODO Visualize
•
•
•
•
•

Bug Trends
Build Status
Performance Report
Technical Debt
Code Quality
Visualize Technical Debt

http://verraes.net/2013/07/managed-technical-debt/
Build Monitor
Checkin Frequently
• Focus your work on small tasks
• Easier to describe what you did in your check-in
comment
• Clear cod...
Team Efforts
• Avoid Shortcuts
• Take collective ownership
Team should own the code
• Promote positive interaction
• Provi...
Guantanamo Code Tool
• All code is guilty until tested innocent
• Do you have problems maintaining high test coverage?

• ...
Agile – the bar is rising

http://blog.gfader.com/2013/05/the-1st-principle-of-agile-manifesto-30.html
Our highest priority is to satisfy the customer

through early and continuous delivery
of valuable software
1st principle ...
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software
1st principle o...
Recap
The important thing isn’t the process

The important thing is the process for
improving your process
Essential skills needed
regardless of process

Splitting the system into
useful pieces

As a buyer
I want to save my shopp...
#TODO TO READ
E. Goldratt “The Goal”

S.Freeman, N.Price GOOS
#TODO References
•
•
•
•

•
•
•

Pragmatics of Agile Development
http://www.agiledeveloper.com/presentations/pragmatics_of...
Now you
1.
2.
3.
4.

Download presentation
Search for #TODO
Get it done
Send me a tweet “I’m done”
Continue the conversation
peter.gfader@zuehlke.com
twitter.com/peitor
http://blog.gfader.com
You cant be agile if your code sucks
You cant be agile if your code sucks
You cant be agile if your code sucks
You cant be agile if your code sucks
You cant be agile if your code sucks
Nächste SlideShare
Wird geladen in …5
×

You cant be agile if your code sucks

24.337 Aufrufe

Veröffentlicht am

What is "Agile"?
Why would someone like to be agile?
What are the 3 pillars for agile software development?
How can you achieve technical excellence in your software teams?
Are developer skills more important than languages, methods or frameworks?

Veröffentlicht in: Technologie
9 Kommentare
10 Gefällt mir
Statistik
Notizen
Keine Downloads
Aufrufe
Aufrufe insgesamt
24.337
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
809
Aktionen
Geteilt
0
Downloads
23
Kommentare
9
Gefällt mir
10
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Click to add notesPeter Gfader
  • 3 ingredients for success
  • 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, ...
  • 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, ...
  • Develop relevant softwareDeliver value earlierCreate value fastWelcome changes and gapsOpen communicationEmpowering peopleKeep it simple
  • 2011 Snowbird
  • Develop relevant softwareDeliver value earlierCreate value fastWelcome changes and gapsOpen communicationEmpowering peopleKeep it simple
  • Purpose of this presentation is to clarify how some of these things fit togetherHow does agile look when done well?
  • 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.
  • Never blame the tool!
  • Vergleichen um zuVerstehen und Lernen und nichtBeurteilen und Schlechtmachen
  • Vergleichen um zuVerstehen und Lernen und nichtBeurteilen und Schlechtmachen
  • 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.
  • Purpose of this presentation is to clarify how some of these things fit togetherHow does agile look when done well?
  • - Communication Skills- Facilitator / ScrumMaster- Vision
  • 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!
  • waste?
  • Sometimes you don’t need well designed codeGoal is not to write tests but to write good code
  • Sometimes you don’t need well designed codeGoal is not to write tests but to write good code
  • Tester
  • Go fast -> Go well
  • 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]
  • You cant be agile if your code sucks

    1. 1. You can’t be Agile if your code sucks Peter Gfader twitter.com/peitor
    2. 2. My Mission #1 Agile?? #2 Code & Craftmanship
    3. 3. About me
    4. 4. Peter Gfader peter.gfader@zuehlke.com http://blog.gfader.com twitter.com/peitor
    5. 5. Agile
    6. 6. What is Agile for you?
    7. 7. http://agilemanifesto.org/
    8. 8. The Agile Manifesto invites 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
    9. 9. What is Agile for you?
    10. 10. What is all this stuff? XP Lean RUP SAFe Agile © Henrik Knieberg
    11. 11. 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
    12. 12. © Henrik Knieberg
    13. 13. The illusion of a ”bad tool” The old tool was better! Don’t blame the tool! © Henrik Knieberg
    14. 14. Compare for understanding, not judgement Key point © Henrik Knieberg
    15. 15. Compare for understanding, not judgement Key point Tools can be combined © Henrik Knieberg
    16. 16. • Know your Goal 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
    17. 17. RUP XP Lean SAFe Agile © Henrik Knieberg
    18. 18. The important thing isn’t the process. © Henrik Knieberg
    19. 19. The important thing isn’t the process. The important thing is the process for improving your process. © Henrik Knieberg
    20. 20. The important thing isn’t the process. The important thing is the process for improving your process. Continuous Improvement © Henrik Knieberg
    21. 21. 3 essential skills needed 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
    22. 22. 3 essential skills needed 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
    23. 23. 3 essential skills needed 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
    24. 24. Essential Skill: Software craftsmanship
    25. 25. 1) Software is never written once and never changed
    26. 26. [LARM03]
    27. 27. 2) How to slow down your project?
    28. 28. Write crappy code  Make code easier to read
    29. 29. Easy code to read  Easy code to change maintain
    30. 30. Why do you write bad code?
    31. 31. #1 reason for Bad code We write bad code, because we read bad code
    32. 32. Code Readings? • • • • Code Reviews Peer Reviews Pair Programming Open source
    33. 33. Good code is like a joke! No need for explanation
    34. 34. #TODO: Code to read 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
    35. 35. #TODO: Review Code • • • • In your team With 1 peer Open source Brown bags – Lunch time discussion
    36. 36. Code Reviews • Code, !Person • Constructively propose changes  Questions!
    37. 37. Code Reviews • Code, !Person • Constructively propose changes  Questions! • Review not only code o Tests o Build process o ..
    38. 38. Code Reviews • Code, !Person • Constructively propose changes  Questions! • Review not only code o Tests o Build process o ..  Grow as a team
    39. 39. Instead of “That lousy long 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”
    40. 40. #2 reason for Bad code Nobody can write good code in 1 sit-in -> Refactoring it’s an art of designing code
    41. 41. #TODO Refactoring https://github.com/NotMyself/GildedRose https://github.com/jcbozonier/Refactoring-Katas
    42. 42. The little issue with Refactoring?
    43. 43. Development With and Without 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!
    44. 44. Refactoring + Tests = ?
    45. 45. Refactoring + Tests = Waste?? Overhead??
    46. 46. 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
    47. 47. Test-Driven Development (TDD) Goal is not to write tests but to write good code RED REFACTOR GREEN
    48. 48. What is Quality
    49. 49. “Why should I care? We have a QA department!”
    50. 50. **** ADD PIC ****
    51. 51. How do you measure Quality?
    52. 52. First Law of Programming “Lowering Quality Lengthens Development Time” http://c2.com/cgi/wiki?FirstLawOfProgramming
    53. 53. Only Quality lets us go faster!
    54. 54. http://manifesto.softwarecraftsmanship.org/
    55. 55. Who?
    56. 56. Quality? • Measure of how well the software is designed and implemented • Subjective
    57. 57. Quality? • • • • • • LOC Code Coverage Class Coupling Cohesion Code Duplication Cyclomatic Complexity
    58. 58. Quality: How to measure? • • • • • • • 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?
    59. 59. Quality: How to measure? • Trends
    60. 60. Quality: How to measure? • Trends • “Output” over time o Velocity - Trend o Business Value - Trend o Bug – Trends • #TODO: How do you measure Business value?
    61. 61. Ways to Improve Quality • 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
    62. 62. Simple Design == High Quality? • • • • Passes its tests Minimizes duplication Maximizes clarity Has fewer elements http://c2.com/cgi/wiki?XpSimplicityRules
    63. 63. #TODO Visualize • • • • • Bug Trends Build Status Performance Report Technical Debt Code Quality
    64. 64. Visualize Technical Debt http://verraes.net/2013/07/managed-technical-debt/
    65. 65. Build Monitor
    66. 66. Checkin Frequently • Focus your 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
    67. 67. Team Efforts • Avoid Shortcuts • Take collective ownership Team should own the code • Promote positive interaction • Provide constructive feedback • Constant code review
    68. 68. 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
    69. 69. Agile – the bar is rising http://blog.gfader.com/2013/05/the-1st-principle-of-agile-manifesto-30.html
    70. 70. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software 1st principle of the Agile Manifesto
    71. 71. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software 1st principle of the Agile Manifesto
    72. 72. Recap
    73. 73. The important thing isn’t the process The important thing is the process for improving your process
    74. 74. Essential skills needed 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
    75. 75. #TODO TO READ E. Goldratt “The Goal” S.Freeman, N.Price GOOS
    76. 76. #TODO References • • • • • • • Pragmatics of Agile 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/
    77. 77. Now you 1. 2. 3. 4. Download presentation Search for #TODO Get it done Send me a tweet “I’m done”
    78. 78. Continue the conversation peter.gfader@zuehlke.com twitter.com/peitor http://blog.gfader.com

    ×