When developing and delivering large, complex systems it can be all too easy to only focus on features and overlook software qualities specific those related to software architecture. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with issues related to evolving the architectures, specifically when trying keeping the system working while making significant improvements when adding functionality. However, time has shown that various Agile practices are not sufficient to prevent or eliminate Technical Debt which can ultimately affect reliability. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture. If there is not enough attention on the architecture and code base, ultimately technical debt will creep in to the point where it can become hard to delivery quickly and with confidence. Two important principle that can help teams deliver more quickly and with confidence is to focus on code quality and delivery size. Small frequently delivery with constant attention to a good code base is crucial to being able to sustain faster delivery with confidence. Often teams evolve to continuous delivery with some limited success, however issues arise when there is not good validation through tests and constant attention to the code quality. Practices that can help keep the code clean or from getting muddier include: Testing, Divide & Conquer, Gentrification, Quarantine, Refactoring, and Craftsmanship. This talk will examine techniques such as Continuous Integration, Continuous Inspection, Continuous Delivery as well as other techniques to pay good attention to code quality allowing teams to delivery more quickly and with confidence.

1. 10/11/2016
1
Deliver Fast
“with confidence”
Joseph W. Yoder
The Refactory
Teams That Innovate
Copyright 2016 Joseph Yoder & The Refactory, Inc.
Twitter: @metayoda
joe@refactory.com
http://www.refactory.com
http://www.teamsthatinnovate.com
11th,

2. 10/11/2016
2
architecture quality can be invisible
…especially when the spotlight is on
FEATURES

3. 10/11/2016
3
The Problem
EBiz
New Products
Features
Mobile
Version
© Can Stock Photo Inc. / alex5248
The Solution
© Can Stock Photo Inc. / Freezingpicture

4. 10/11/2016
4
What’s below
the waterline?
all those “ilities”
we can’t ignore
…
Reliability
Scalability
Stability
Maintainability
Performance
© Can Stock Photo Inc. / SergeyNivens
8

5. 10/11/2016
5
Code Rot
Is it better to
clean little by
little?
Or to let dirt
and mess
accumulate?

6. 10/11/2016
6
Neglect Is Contagious
Disorder increases and software rots over time.
Don’t tolerate a broken window.
http://www.pragmaticprogrammer.com/ppbook/extracts/no_broken_windows.html
Some dirt becomes
very hard to clean
if you do not clean
it right away!
Technical Debt?

7. 10/11/2016
7
Values Drive Practices

8. 10/11/2016
8
Agile/Lean Design Values
 Core values:
 Design Simplicity
 Quick Feedback
 Frequent Releases
 Continuous Improvement
 Teamwork/Trust
 Satisfying stakeholder needs
 Building Quality Software
 Keep Learning
 Lots of Testing!!!
Agile Practices
TDD
Scrum

9. 10/11/2016
9
Sustaining Your Architecture
Some Agile Myths
 Simple solutions are always best
 We can easily adapt to changing
requirements (new requirements)
 Scrum/TDD will ensure good
Design/Architecture
 Good architecture simply emerges
from “good” development practice
 You always go fast when doing agile
 Make significant architecture
changes at the last moment
“www.agilemyths.com”
Continuous Improvement
“Retrospectives are Key!!!”
Small Steps we can take - next sprint!!!

10. 10/11/2016
10
Refactoring
“If you value clean code…”
Clean Code Doesn't Just Happen
•You have to craft it
•You have to maintain it
•You have to make a professional commitment
“Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.”
– Martin Fowler

11. 10/11/2016
11
Professional Responsibility
There’s no time to wash hands, get to the next patient!
Professionalism
Make it your responsibility to create code that:
Delivers business value
Is clean
Is tested
Is simple
Follows good design principles
When working with existing code:
If you break it, you fix it
You never make it worse than it was
You always make it better

12. 10/11/2016
12
Code Bad Smells
Have you ever looked at
a piece of code that
doesn't smell very nice?
A code smell is any
symptom in the
source code that can
indicate a problem!
Ten Most Putrid List
1) Sloppy Layout,
2) Dead Code,
3) Lame Names,
4) Commented Code,
5) Duplicated Code,
6) Feature Envy,
7) Inappropriate Intimacy,
8) Long Methods & Large Class,
9) Primitive Obsession & Long Parameter List,
10) Switch Statement & Conditional Complexity …
0) Magic Numbers,

13. 10/11/2016
13
Sustaining Your Architecture
Safe Refactorings
Rename is always safe!!!
New Abstract Class moving
common features up
Extract Method (always safe)
Extract Interface / Extract Constant
Pull Up / Push Down
Create common component
for shared internal methods
 Fairly safe but can be harder to share
Two Refactoring Types*
Floss Refactorings—frequent, small
changes, intermingled with other
programming
(daily health)
Root canal refactorings—infrequent,
protracted refactoring, during which
programmers do nothing
else (major repair)
* Emerson Murphy-Hill and Andrew Black in
“Refactoring Tools: Fitness for Purpose”
http://web.cecs.pdx.edu/~black/publications/IEEESoftwareRefact.pdf

14. 10/11/2016
14
But We Don’t Have Time!
Kaizen
The Sino-Japanese word "kaizen" simply means
"change for better", with no inherent meaning of
either "continuous" or "philosophy" in Japanese
dictionaries or in everyday use. The word refers to
any improvement, one-time or continuous, large or
small, in the same sense as the English word
"improvement". (Wikipedia)
Most view it as Continuous Improvement…

15. 10/11/2016
15
Slack Time
Key Principle:
Need Slack time to improve
Ways to get slack time…
 Monitor and Make Visible
 Reduce Waste (Muda)
 Inject time into process
(retros, daily cleanup, …)
Try little experiments…
Kaizen
Spotify: Innovation

16. 10/11/2016
16
Regular Practices
Allocate time for dealing with tech debt
Team building and education sessions
Evaluate and Reflect…small changes
Delivery Size is Key
Large Delivery Size can cause many issues
Issues:
 More potential defects
 Longer time to get feedback
 Slower adjust time
 Harder to experiment

17. 10/11/2016
17
HOW SYSTEM QUALITY WORK
CAN FIT INTO YOUR RHYTHMS
“QUALITY IS NOT AN ACT, IT IS A HABIT.”
—ARISTOTLE
Build architectural quality into your project rhythms

18. 10/11/2016
18
Qualify the Backlog
You can add backlog items for technical debt and
quality-related architecture work… yes, you can
Make Architecture Work
Visible and Explicit
http://philippe.kruchten.com/2013/12/11/the-missing-value-of-software-architecture/
Visible Feature
Invisible Architectural
Feature
Visible Defect Technical Debt
Color your backlog—Phillipe Kruchten
Positive Value
Negative Value
Visible Invisible

19. 10/11/2016
19
Plan a Sprint
Product
Envisioning
/
Roadmap
Deploy to
Stakeholders
Functional
Acceptance
Testing
Develop
and Manage
the Backlog
Run a Sprint
Daily Review
Incorporate Feedback
How Quality Fits
Into An Agile Process
Identify:
Architecture Risks
Key Quality Scenarios
Landing Zone Criteria
Can
Include
Quality
Items
Quality
Testing
Include
relevant
quality
tasks
Test Driven Development

20. 10/11/2016
20
Define Architecture Triggers
• Conditions that
cause architecture
investigation/ tasks
– Quality target
no longer met
– Code quality
metrics violations
– …
• Have broad
system impact
ONGOING QUALITY ACTIVITIES

21. 10/11/2016
21
Monitor System Qualities—
Build An Operational Dashboard
Sustaining Your Architecture
Continuous Inspection
Asian PLoP 2014 Paper
CODE SMELL DETECTION
METRICS (TEST COVERAGE,
CYCLOMATIC COMPLEXITY,
TECHNICAL DEBT, SIZES, …)
APPLICATION SECURITY CHECKS
ARCHITECTURAL CONFORMANCE
AUTOMATE WHERE YOU CAN!!!

22. 10/11/2016
22
Periodically Re-Evaluate
Architecture Risks
Iteration
Planning
Implementation
Delivery and
Feedback
Continuous Improvement
Architecture Quality
PAUSE POINTS HELP

23. 10/11/2016
23
Quality Focused
Checklists
• Release Checklists*
– Agreed upon checklist
for quality and major
architecture concerns
• Use at pause points
– sprint planning,
release planning,
…
*Thanks, James Thorpe for
sharing your company’s checklist
Two Kinds of
Checklists
1.Read-review
2.Do-confirm

24. 10/11/2016
24
*Thanks, Alex Balboaca for sharing
Checklists at MozaicWorks*
Where do you start?
• Small quick releases
• Monitor qualities
• Pick some low hanging fruit
– Make goals visible
– Colorize your backlog
– Create quality-related
checklists
• Spread attention to code
quality throughout teams
• Depends on where you are
and where the pain is…
© Can Stock Photo Inc. / iqoncept

25. 10/11/2016
25
How Much Architecture
Risk do you Have?
• New architecture, new product,
new market, new technologies
• Transforming an existing product
• Evolving a product
• Feature extensions on a
“stable” architecture
Higher
Lower
“the more risk, the more attention you need to pay to architecture”
How Big is your Project?
Small v. Large Projects
Small Projects
• 6-8 people
• Non-life critical
• Known domain
Large Projects
• Multiple teams
• Known domain
but tackling a big
problem
• “Naturally”
emerging architecture can
reflect organization structure
• Significant risks, challenges,
unknowns, lots of coordination
architecture needs explicit attention
architecture typically evolves
OK without much attention

26. 10/11/2016
26
VALUES DRIVE PRACTICE
CALL TO ACTION
Daily Practices
Sustainable Development
(CC) by muffinn on Flickr
Visibility
Lazy Manifesto
Keeping slack over fully utilizing all the time
Small high quality software over
large complex software
Doing only what is necessary over
exhaustively discovering all tasks
Doing less to deliver the same over
doing more to deliver less
“We are uncovering lazier ways of developing valuable
products by doing it and helping others to do it.
Through this work we have come to value:”
That is, while there is value in the items on the right,
we value the items on the left more…

27. 10/11/2016
27
Principles of Lazy Manifesto
Doing nothing is always an option.
We seek to minimize the number of backlog items while keeping the value of the backlog.
We believe to keep increasing velocity is not always good.
We try to eliminate tasks that generate no value.
We try to combine tasks to reduce latency and rework.
We try to rearrange tasks to find problems early.
We try to simplify all tasks as much as possible
We are not afraid of eliminating our own tasks / processes
by continuously acquiring new skills / capabilities.
We expand capabilities over increasing capacities.
We only work hard to make our work easier and safer.
We always look to get help while we provide help to others with minimum effort.
We never try to add an unnecessary principle simply to match with the other manifesto :)
“We follow these principles when they don’t add work:”
It is a Journey
Commitment
Follow-through
Deliberate practices
Paying attention
Small Fast Delivery
Continuous Learning
© Can Stock Photo Inc. / jefras

28. 10/11/2016
28
Agile Mindset
Being AgileBeing vs Doing
Core Ideas / Takeaways
• Values drive practice
• Continues Improvement
• Code Quality and Delivery Size
• Deal with Technical Debt
• Many Practices can help
• Call To Action (small steps you can take)

29. 10/11/2016
29
Additional Resources
• The Hillside Group (patterns community): Hillside.net
• Being Agile at System Qualities workshop:
– www.adaptiveobjectmodel.com/2015/04/
qa-to-aq-shifting-towards-agile-quality
• Agile Myths: agilemyths.com
• The Refactory (www.refactory.com)
• Teams That Innovate (www.teamsthatinnovate.com)
• Pragmatic TDD :
refactory.com/training/test-driven-development
http://adaptiveobjectmodel.com/2012/01/
what-is-pragmatic-tdd
Kaizen
Joe’s cool photo goes here!!!
joe@refactory.com
Twitter: @metayoda
www.joeyoder.com
www.refactory.com
Dziękuję!!!