Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
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.425 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

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

×