Teams fail to achieve the full benefit of the "clean code" approach when they focus on the code and neglect the Agile process. The full title of Uncle Bob's "Clean Code" book is "Clean Code: A Handbook of Agile Software Craftsmanship". This talk presents an depth look at necessary relationship between Clean Code software craftsmanship and the Agile methodology, identifies common scenarios and situations where teams may fall short of recognizing and respecting that relationship, and provides practical recommendations for achieving a fully integrated process of Agile Software Craftsmanship. Robert Martin's book "Clean Code: A Handbook of Agile Software Craftsmanship" had a huge positive impact on software development teams that adopted his approach to "Agile Software Craftsmanship". But teams sometimes fail to achieve the full benefit of the "clean code" approach because they focus on the code and neglect the Agile process. It's easy to do: the book provides such clear, practical advice on how to write code that is easier to maintain, more reliable, and less error prone that developers adopt those techniques to great effect and fail to pursue and adopt the harder, agile process recommendations from the book. This is further complicated by the fact that there is now a Software Craftsmanship Manifesto that is separate from the Agile Manifesto. So, how does using selected clean code techniques break the Agile process defined in the the book? What is the relationship between the two that Uncle Bob wanted us to understand and adopt in toto? Where do we go wrong? Are there some work environment or business driven scenarios that are more likely to break the relationship? This presentation addresses those questions and more by an taking an in depth look at necessary relationship between Clean Code software craftsmanship and the Agile methodology, identifies common scenarios and situations where teams may fall short of recognizing and respecting that relationship, and provides practical recommendations for achieving a fully integrated process of Agile Software Craftsmanship.

1. Rob Curry
robert.curry@daugherty.com
February 22, 2018
Why Isn’t Clean Coding Working For My Team?

3. http://agilemanifesto.org

4. http://manifesto.softwarecraftsmanship.org

5. Software Craftsmanship Extends Agile
Software Development
Agile Software Development
• Individuals and interactions
over processes and tools
• Responding to change over
following a plan
• Customer collaboration
over contract negotiation
• Working software over
comprehensive
documentation

6. Software Craftsmanship Extends Agile
Software Development
Agile Software Development
• Individuals and interactions
over processes and tools
• Responding to change over
following a plan
• Customer collaboration
over contract negotiation
• Working software over
comprehensive
documentation
Software Craftsmanship
• But also a community of
professionals

7. Software Craftsmanship Extends Agile
Software Development
Agile Software Development
• Individuals and interactions
over processes and tools
• Responding to change over
following a plan
• Customer collaboration
over contract negotiation
• Working software over
comprehensive
documentation
Software Craftsmanship
• But also a community of
professionals
• But also steadily adding
value

8. Software Craftsmanship Extends Agile
Software Development
Agile Software Development
• Individuals and interactions
over processes and tools
• Responding to change over
following a plan
• Customer collaboration
over contract negotiation
• Working software over
comprehensive
documentation
Software Craftsmanship
• But also a community of
professionals
• But also steadily adding
value
• But also productive
partnerships

9. Software Craftsmanship Extends Agile
Software Development
Agile Software Development
• Individuals and interactions
over processes and tools
• Responding to change over
following a plan
• Customer collaboration
over contract negotiation
• Working software over
comprehensive
documentation
Software Craftsmanship
• But also a community of
professionals
• But also steadily adding
value
• But also productive
partnerships
• But also well-crafted
software

10. What constitutes “working” for a
team?

11. What constitutes “working” for a
team?
• Delivering working software at the end of
every sprint or iteration?

12. What constitutes “working” for a
team?
• Delivering working software at the end of
every sprint or iteration?
• Reduced fear when touching legacy code?

13. What constitutes “working” for a
team?
• Delivering working software at the end of
every sprint or iteration?
• Reduced fear when touching legacy code?
• Institutional flexibility?

14. What constitutes “working” for a
team?
• Delivering working software at the end of
every sprint or iteration?
• Reduced fear when touching legacy code?
• Institutional flexibility?
• Raising the perceived level of professionalism
of the team within the organization?

15. And how do we determine that
software is well crafted?

16. And how do we determine that
software is well crafted?
• Low defect rate?

17. And how do we determine that
software is well crafted?
• Low defect rate?
• Few re-opened issues?

18. And how do we determine that
software is well crafted?
• Low defect rate?
• Few re-opened issues?
• It’s easy to make changes without breaking
other functionality?

19. And how do we determine that
software is well crafted?
• Low defect rate?
• Few re-opened issues?
• It’s easy to make changes without breaking
other functionality?
• High level of reliability and maintainability?

20. And how do we determine that
software is well crafted?
• Low defect rate?
• Few re-opened issues?
• It’s easy to make changes without breaking
other functionality?
• High level of reliability and maintainability?
• Comprehensive test coverage?

21. And how do we determine that
software is well crafted?
• Low defect rate?
• Few re-opened issues?
• It’s easy to make changes without breaking
other functionality?
• High level of reliability and maintainability?
• Comprehensive test coverage?
• Works “as expected”?

22. Track and measure what makes sense
for your team!
• As a team, you have to define this
• Whatever you choose , make sure you check
and recalibrate often to make sure you remain
on track
• Measure continuously where you can (e.g.,
every commit, every build)
• Document and communicate your definition
of “working”

23. Reasonable Expectations
The Code
• The intention of the developers is clear in every part of
the code
• The code has great test coverage (tests both reflect and
promote clear intent)
• The code is easy to maintain (because of great test
coverage)
• The code functions as expected (no side effects or
hidden dependencies)
• There are fewer bugs
– Bob Martin says that code that is hard to understand gets
ignored, and that’s where bugs hide.

24. Reasonable Expectations
The Team
• Work can be planned and delivered with greater
consistency
• Quality Assurance can focus on new business
functionality and less on regression testing
(because of great test coverage)
• It’s easier to address changing business needs,
even late in the product development process
• Improved relationships with across partnerships
as the team consistently delivers clean code

25. Reasonable Expectations
The Business
• has real agility with respect to changing
market conditions
• has real agility with respect to changing
technologies
• has less developer turnover
• has more cross-team collaboration

26. What Gets In The Way?

27. What Gets In The Way?

28. Getting Back On Track
• Knowledge (easiest to correct)
– Training: lots of options these days beyond formal
and costly training
– Pair Programming: solves lack of experience and
developers being too busy
– Clean coding techniques: address all areas
because the code is easier to understand, easier
to change, and works as expected

29. Getting Back On Track
• Information (discipline and standards)
– Standards for code formatting make it easier to
track and compare code changes over time
– Pair Programming and TDD: bring intention to the
forefront and promote information exchange
– Say “No” to ambiguous requirements and
impossible timelines
• Bob Martin says, “A promise to try is an admission
you’ve been holding back…”

31. Getting Back On Track
Attitude (very challenging to address)
• Software Craftsmanship is about committing
oneself to excellence & continuous improvement
– Use the language of commitment with your team.
• Agile principles say “Build projects around
motivated individuals”, but we don’t always have
that freedom
– Make sure the developers know how their efforts
contribute to the success of the team and the
business
– Regularly recognize individual achievements

32. Getting Back On Track
Attitude (continued)
• There must be zero tolerance for bad attitudes and
unprofessional behavior
– Take the individual aside – never dress someone down in front
of the team
– Face-to-face conversation is the best way to confront this
– Make every attempt to find the “real” problem – a bad attitude
is often a symptom of some deeper problem
• Cowboys & Passive/Aggressive behaviors:
– ensure standards & guidelines are in place for code style,
branching strategy, etc.
– Failure to comply/follow rules then is not an adversarial
situation and is not personal.

33. Getting Back On Track
Attitude (continued)
• Conduct retrospectives for every iteration
– great way to identify issues at the individual level
– this is also a time to use the language of
commitment when assigning action items
• Every heated discussion is an opportunity to
identify a problem affecting the team
• Heated discussions are never a way to solve a
problem

34. What Gets In The Way?

35. Getting Back On Track
Team Behaviors
• Relaxing discipline to meet delivery schedules is a
slippery slope; don’t do it! Message sent is that all
standards and practices are negotiable.
– Review the standards and practices and ask team to
recommit
• Treating some developers as special
– It breaks trust among the team members and business
collaborators (trust me, they’ll notice)
– Directly defeats clean coding – back to confusing code,
reduced test coverage, code duplication, unclear intention,
etc.

36. Getting Back On Track
Team Behaviors
• Saying Yes
– Know when to say No
– Creates a chronic problem as business comes to
expect it
– Overworked, tired developers don’t write clean code
• Refactoring – Bob Martin is clear on this: truly
clean code is hard to achieve without refactoring
– Allow for refactoring cycles in your delivery timelines
– When clean coding is working for your team, this is
easier for the business to understand and accept

37. What Gets In The Way?

38. Getting Back On Track
• Corporate Behaviors - most challenging area to fix for your
team; much of this is outside of your control
– Ambiguous priorities, constant redirection, rushing to
target can be addressed by saying “No” (to the degree that
team is empowered)
– Withheld information, communication barriers can be
mitigated by leveraging your relationships with business
partners and other teams
– Inadequate training budgets: send one or two team
members and have them share with team
– Development teams working together to share results and
success stories of clean coding with the business stand the
best chance of influencing corporate behavior

39. In Conclusion

40. In Conclusion
• The agile software development discipline of clean coding will
produce well-crafted software and promote professionalism at all
levels of a business.

41. In Conclusion
• The agile software development discipline of clean coding will
produce well-crafted software and promote professionalism at all
levels of a business.
• Clean coding is about more than just the code.

42. In Conclusion
• The agile software development discipline of clean coding will
produce well-crafted software and promote professionalism at all
levels of a business.
• Clean coding is about more than just the code.
• What is good for agile software development is good for clean
coding.

43. In Conclusion
• The agile software development discipline of clean coding will
produce well-crafted software and promote professionalism at all
levels of a business.
• Clean coding is about more than just the code.
• What is good for agile software development is good for clean
coding.
• What is bad for agile software development is bad for clean coding.

44. In Conclusion
• The agile software development discipline of clean coding will
produce well-crafted software and promote professionalism at all
levels of a business.
• Clean coding is about more than just the code.
• What is good for agile software development is good for clean
coding.
• What is bad for agile software development is bad for clean coding.
• To paraphrase Robert Martin (and the Boy Scouts), leave the code
cleaner than you found it.
• Carl Buehner – “They may forget what you said, but they will never
forget how you made them feel.”
– If you want to be recognized as being a professional, act like one, always!

45. In Conclusion
• The agile software development discipline of clean coding will
produce well-crafted software and promote professionalism at all
levels of a business.
• Clean coding is about more than just the code.
• What is good for agile software development is good for clean
coding.
• What is bad for agile software development is bad for clean coding.
• To paraphrase Robert Martin (and the Boy Scouts), leave the code
cleaner than you found it.
• There is much more to clean coding than can be covered in an hour.
Google is your friend–start with any name from the manifesto main
page.