Dextra mud-sustaining architecture withrefactoring

5/16/2016
1
Joseph W. Yoder -- www.refactory.com
www.teamsthatinnovate.com
Taming Big Balls of Mud
with Agile, Diligence and
Lot’s of Hard Work
Copyright 2016 Joseph W. Yoder & The Refactory, Inc.
May 16th, 2016
Sustainable
Architecture
Copyright 2014 Joseph W. Yoder & The Refactory, Inc.
Joseph W. Yoder -- www.refactory.com

5/16/2016
2
Sustaining Your Architecture
Introductions
Where are you from?
A little background…
Evolved from UIUC SAG
In the early 90’s we were studying objects,
frameworks, components, meta, refactoring,
reusability, patterns, “good” architecture.
However, in our SAG group we often noticed
that although we talk a good game, many
successful systems do not have a good
internal structure at all.

5/16/2016
3
Selfish Class
Brian and I had just published a paper
called Selfish Class which takes a code’s-
eye view of software reuse and evolution.
In contrast, our BBoM paper noted that in
reality, a lot of code was hard to (re)-use.
Big Ball of Mud
Alias: Shantytown, Spaghetti Code
A BIG BALL OF MUD is haphazardly
structured, sprawling, sloppy, duct-tape and bailing
wire, spaghetti code jungle.
The de-facto standard software
architecture. Why is the gap
between what we preach and
what we practice so large?
We preach we want to build high quality
systems but why are BBoMs so prevalent?

5/16/2016
4
Worse is Better
Ideas resembles Gabriel’s 1991
“Worse is Better”
Worse is Better is an argument to
release early and then have the
market help you design the final
product…It is taken as the first
published argument for open
source, among other things
Do BBoM systems have a Quality?
What exactly do we
mean by "Big"?
Well, for teams I consider > 10^2 big
and for code I consider > 10^5 big

5/16/2016
5
Legacy == Mud?
Legacy != Mud???
Does Legacy happen within months or a year
after the first release?
Or is legacy after the second release?
What about Muddy code that is released on the
first version? Is this a counterexample?
Is all Legacy Mud?

5/16/2016
6
Messy Code
Have you been significantly impeded by messy code?
With permission from: Mrs D. http://www.belly-timber.com/2005/10/03/embracing-our-inner-web-stat/
Designs Naturally Degrade
• All designs evolve.
• Code rots as changes are made unless it is kept clean.
• Entropy increases over time.
class Pair
{
private:
Object first_;
Object second_;
Object third_;
public:
Pair() { }
Pair( Object first, Object second, Object third )
:first_(first), second_(second), third_(third)
{}
// etc.
};

5/16/2016
7
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
Where Mud Comes From?
People Write Code  People make Mud

5/16/2016
8
Keep it Working, Piecemeal
Growth, Throwaway Code
Copy ‘n’ Paste

5/16/2016
9
Transitional Technologies
Precursors of Ambient
Computing Era
1950 1960 2000 2010 2020199019801970
SocietalImpact
Personal Computing
Corporate Computing
Ambient
Computing
WWW/Browsers
Cell phones
http://www.wirfs-brock.com/allen/posts/category/post-pc-computing
Apps on Browser Platforms
Apps are becoming the norm
running on whatever platform

5/16/2016
10
The Age of
Sampling
Big Bucket
of Glue&
The Mystery of Dark Matter
Accidental Complexity??? Maybe our
current state of the art leads to Mud!

5/16/2016
11
Is Mud Normal?
Well, just read our paper....there are
"normal" reasons why it happens
If mud is such a bad thing, why
do people keep making it?
Maybe if we accept and teach it
then we can deal with it better and
help prevent it from getting too bad
Mud Discussion
Discuss some mud
you have seen!
How did it happen
and what problems
did it cause?

5/16/2016
12
Technical Debt
Term invented by
Ward Cunningham
Piles up when you
continually implement
without going back
to reflect new
understanding
Can have long
term costs and
consequences
Agile to the Rescue???
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
…From the Agile Manifesto

5/16/2016
13
Continuous Improvement
“Retrospectives are Key!!!”
1) What worked well that we do not
want to forget for future iterations?
2) What should we do differently?
there should be no finger pointing…
do not focus on negative things
3) What still puzzles us?
Things we can't answer
4) What did you learn?
5) Hopes for the next iteration/release
6) Take small action steps – next sprint
Can Agile Help?
Scrum, TDD, Refactoring, Regular Feedback
Continues Integration, Testing, More Eyes, …
Good People!!!
Continuous attention to technical excellence!
Retrospectives!
Face-To-Face conversation.
Motivated individuals with the
environment and support they need.

5/16/2016
14
Agile Design Values
 Core values:
 Design Simplicity
 Communication
 Continuous Improvement
 Teamwork / Trust
 Satisfying stakeholder needs
 Keep learning
 Continuous Feedback
 Lots of Testing/Validation!!!
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 practices.
Sometimes you need more.
 Make significant architecture
changes at the last moment.
“www.agilemyths.com”

5/16/2016
15
Do Some Agile Principles
Encourage bad design?
Lack of Upfront Design?
Late changes to the requirements
of the system?
Continuously Evolving the Architecture?
Piecemeal Growth?
Focus on Process rather than Architecture?
Working code is the measure of success!
I’m sure there are more!!!
Craftsmanship?

5/16/2016
16
Quality
Quality Definition: a peculiar and essential
character or nature, an inherent feature or
property, a degree of excellence or grade, a
distinguishing attribute or characteristic
Quality (Who’s perspective)
ScientistArtist
EngineerDesigner
important/boring true/false
cool/uncool good/bad
Rich Gold "The Plenitude: Creativity, Innovation & Making Stuff
(Simplicity: Design, Technology, Business, Life)“
Triggers and Practices – Richard Gabriel http://www.dreamsongs.com
An architect
might have
perspectives
from an artist
to a design or
an engineer!
“The Four Winds of
Making”…Gabriel

5/16/2016
17
Design is about Tradeoffs
 Usability and Security often
have orthogonal qualities
 Designing Interfaces: Patterns
for Effective Interaction Design
 Security Patterns: Integrating
Security and Systems Engineering
 Performance vs Small Memory
• Quality of being good enough
Secure
Usable Cheap
Being Good Enough
 Quality of being good enough.
 Does it meet the minimum requirements
 Quality has many competing forces…are
we designing a system for online orders or
for controlling the space shuttle, they have
different qualities, thus different patterns
and solutions apply.
 Perfection is the enemy of Good Enough!
 Maybe Quality without a Number.

5/16/2016
18
Does Quality Code Matter?
Patterns about creating quality code that
communicates well, is easy to understand,
and is a pleasure to read. Book is about
patterns of “Quality” code.
But…Kent states, “…this book is built on a fragile
premise: that good code matters. I’ve seen too
much ugly code make too much money to believe
that quality of code is either necessary or sufficient
for commercial success or widespread use.
However I still believe quality of code matters.”
Patterns assist with making code more bug
free and easier to maintain and extend.
Cleaning House
Can we gentrify, rehabilitate,
or make-over code helping
clean up the mud?
Can refactoring, patterns, frameworks,
components, agile, and objects help
with mud?
Is it possible to do some Mud Prevention
and keep our Architecture Clean?

5/16/2016
19
How can we even start?
How can we cordon off the mess?
If we have a BBoM
Sweep It Under the Rug
Cover it up to keep other areas clean
(Façade and other Wrapper Patterns)

5/16/2016
20
Code Make Over
Refactoring can help reverse some mud. The
tradeoff is cost and time....maybe with technology
Refactoring to Better Design (Patterns)…
Refactorings
Behavior Preserving Program
Transformations
• Rename Instance Variable
• Promote Method to Superclass
• Move Method to Component
Always done for a reason!!!
Refactoring is key and integral
to most Agile processes!!!
TDD

5/16/2016
21
A Simple Refactoring
Object
Concrete1 Concrete2
Object
Concrete1 Concrete2
NewAbstract
Create Empty Class
Borrwed from Don Roberts, The Refactory, Inc.
A Complex Refactoring
Refactoring can be hard but there are a lot of
small steps that lead to big gains in mud busting
Borrowed from Don Roberts, The Refactory, Inc.
Array
Matrix
Matrix
MatrixRep
ArrayRep
rep
SparseRep IdentityRep

5/16/2016
22
Transform Design
with Small Steps
Extract Method
Move Method
Replace Conditional with Polymorphism
Test
Test
Test
Test
Rename
OR
Refactoring Impact On Tests
Extensive rework
Some rework
Little or no rework

5/16/2016
23
Code Smells
A code smell is a hint that something has gone
wrong somewhere in your code. Use the smell
to track down the problem… Kent Beck
Bad Smells in Code was an essay
by KentBeck and MartinFowler,
published as Chapter 3 of:
Refactoring Improving The
Design Of Existing Code.
----Ward’s Wiki
Have you ever
looked at a piece of
code that doesn't
smell very nice?
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 …

5/16/2016
24
Bad Formatting
void foo(int x[], int y, int z){
if (z > y + 1)
{
int a = x[y], b = y + 1, c = z;
while (b < c)
{
if (x[b] <= a) b++; else {
int d = x[b]; x[b] = x[--c];
x[c] = d;
}
}
int e = x[--b]; x[b] = x[y];
x[y] = e; foo(x, y, b); bar(x, c, z);
}}
void bar(int i[], int j, int k)
{ return i[j] = int [k]}
Dead Code
void foo(int x[], int y, int z) {
if (z > y + 1) {
int a = x[y], b = y + 1, c = z;
while (b < c) {
if (x[b] <= a) b++; else {
int d = x[b]; x[b] = x[--c];
return;
x[c] = d;
}
x[b] = a;
}
y = 5; // set y equal to 5
int e = x[--b]; x[b] = x[y];
x[y] = e; foo(x, y, b);
/* used to use bar,
might need it again
bar(x, c, z); */
}
void bar(int i[], int j, int k) {
/* bar method returning nothing */
if (j > k) {
return k
i[k] = i[j];
}
if (j == k) {
return i[j] = int [k]
}
}

5/16/2016
25
Fix the Layout and
Remove Useless Items
Format the Code Consistently
Agree on a standard format
Set the tools for consistent formatting
Run the tools over the code base
Remove Unreachable Code
Delete useless comments
Delete commented out code
Remove code that can’t be reached,
Lame Names
void foo(int x[], int y, int z)
{
if (z > y + 1)
{
int a = x[y], b = y + 1, c = z;
while (b < c)
{
if (x[b] <= a) b++; else {
int d = x[b]; x[b] = x[--c];
x[c] = d;
}
}
int e = x[--b]; x[b] = x[y];
x[y] = e; foo(x, y, b);
foo(x, c, z);
}
void quicksort(int array[], int begin, int end) {
if (end > begin + 1) {
int pivot = array[begin],
l = begin + 1, r = end;
while (l < r) {
if (array[l] <= pivot)
l++;
else
swap(&array[l], &array[--r]);
}
swap(&array[--l], &array[beg]);
sort(array, begin, l);
sort(array, r, end);
}
}
http://dreamsongs.com/Files/BetterScienceThroughArt.pdf

5/16/2016
26
Fixing Names
Names should mean something.
Standards improve communication
- know and follow them.
Standard protocols
object ToString(), Equals()
ArrayList Contains(), Add(), AddRange()
Remove(), Count, RemoveAt(),
HashTable Keys, ContainsKey(),
ContainsValue()
Standard naming conventions
Introduce Explaining Variable
if (basePrice > 1000)
return _quantity * _itemPrice; * 0.95;
else
return _quantity * _itemPrice; * 0.98
double basePrice = _quantity * _itemPrice;
return basePrice * 0.95;
else
return basePrice * 0.98
Could evolve to apply Replace Temp with Query Refactoring

5/16/2016
27
Replace Temp with Query
double basePrice = _quantity * _itemPrice;
return basePrice * 0.95;
else
return basePrice * 0.98
if (basePrice() > 1000)
return basePrice() * 0.95;
else
return basePrice() * 0.98
double basePrice() {
return _quantity * _itemPrice;}
Comments
We are not against comments but…
If you see large methods that have places
where the code is commented, use Extract
Method to pull the commented code into a
helper method that is called
void printOwing (double amount) {
printBanner();
//print details
System.out.println (name: “ + _name);
System.out.println (amount: “ + amount);
…}

5/16/2016
28
Comments Example
printBanner();
//print details
System.out.println (amount: “ + amount);
…}
Comments indicate
"identifiable task”
printBanner();
printDetails();
…}
void printDetails (double amount) {
System.out.println (amount: “ + amount);}
If you need to comment a block of
code, it probably should be a
separate method
Turn method comment
into method name
Duplicate Code
 Do everything exactly once
 Duplicate code makes the system
harder to understand and maintain
 Any change must be duplicated
 The maintainer has to change every copy

5/16/2016
29
Fixing Duplicate Code
 Do everything exactly once!!!
 Fixing Code Duplication
 Move identical methods up to superclass
 Move methods into common components
 Break up Large Methods
REUSE
Do not
duplicate!
DRY Principle
Consolidate Duplicate
Conditional Fragments
if (isSpecialDeal()) {
total = price * 0.95;
send();
}
else {
send();
}
if (isSpecialDeal())
else
send();

5/16/2016
30
Consolidate Duplicate Test Impact
There should be no impact since
the interface to the original
method containing the
conditional has not changed.
All tests should still pass!!!
Long Method
Large Class
Classes and methods which accumulate
soo much functionality
Hard to reuse and test
A hint that it has
more responsability
than it should

5/16/2016
31
Extract Method
Extract a piece of source code to a new
method in the same class.
 Create a new method
 Copy the source code
 Identify parameters
 Identify return
 Update references
Extract Method
void printOwing(double amount) {
printBanner();
//print details
System.out.println(“name:” + _name);
System.out.println(“amount:” + amount);
……a lot more details….
printFooter();
}
printBanner();
printDetails(amount);
printFooter();
}
void printDetails (double amount) {
System.out.println(“name:” + _name);
System.out.println(“amount:” + amount);
……a lot more details….}

5/16/2016
32
Extract Method Test Impact
Previous Tests should still pass - 100%!
• Original tests for the method should still pass.
There might be no necessary changes to your
tests for this refactoring.
However, you might want a new unit test for the
new method…specifically if it is going to be
reused!
Inappropriate Intimacy
When classes depend on other’s
implementation details …
Tightly coupled classes -
you can’t change one with-
out changing the other.
Boundaries between
classes are not
well defined.

5/16/2016
33
Feature Envy
When a class uses a lot the functionality
or features of another class
Indicates that some functionality is in
the wrong class … “Move Method”
It creates a tight
coupling between
these two classes
Move Method
Move a method from one class to other
class where it is more suitable.
 Create a method on
the other class
 Copy the method from
the source code
 Change method parameter
to this object
 Update references

5/16/2016
34
Move Method Impact
This can cause you to refactor your old
tests to remove any tests that access
that original method and possibly create
new tests for the class where the
method was moved to.
The rest of the tests should stay the same
and once the tests are refactored
everything should still pass all tests!!!
Switch Statements
Many switch statements or nested
conditionals throughout methods
Rather than switching use method names
to do the cases (double dispatch)
Use polymorphism or overriding of hook
methods (new cases do not change
existing code)

5/16/2016
35
Replace Nested Conditional
with Guard Clauses
 A method has conditional behavior that
does not make clear the normal path of
execution.
 Use guard clauses for the special cases!
Replace Nested Conditional
with Guard Clausesdouble getPayAmount() {
double result;
if (_isDead) result = deadAmount();
else {
if (_isDisabled) result = disabledAmount();
else {
if (_isRetired) result = retiredAmount();
else lot’s of code … result = normalAmount;}}
return result;}
double getPayAmount() {
if (_isDead) return deadAmount();
if (_isDisabled) return disabledAmount();
if (_isRetired) return retiredAmount();
lot’s of code….return normalAmount;}

5/16/2016
36
Replace Nested Conditional With
Guard Clause Test Impact
There should be no impact since the interface
to the original method containing the
conditional has not changed.
All tests should still pass!!!
You have a conditional that chooses
different behavior depending on the
type of an object.
Move each leg of the conditional to an
overriding method in a subclass.
Make the original method abstract!
Replace Conditional
with Polymorphism

5/16/2016
37
Replace Conditional
with Polymorphism
double getSpeed() {
switch (_type) {
case EUROPEAN:
return getBaseSpeed();
case AFRICAN:
return getBaseSpeed() -
getLoadFactor() *
_numberOfCoconuts;
case NORWEGIAN_BLUE:
return (_isNailed) ?
0 :
getBaseSpeed(_voltage);
}
throw new RuntimeException
("unreachable");
}
Replace Conditional with
Polymorphism Test Impact
This can cause you to refactor your old
tests that were testing the conditional
logic in the old class.
The rest of the tests should stay the
same and once the tests are refactored
everything should still pass all tests!!!
However, you may need to write many
new tests for the subclasses for the
new conditional!!

5/16/2016
38
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 …
Code Smell Discussion
Discuss some code
smells you have seen!
How did they happen
and what problems
did they cause?

5/16/2016
39
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
Safe Refactorings
Rename is always safe!!!
New Abstract Class moving
common features up
Extract Method (always safe)
Moving Same Methods/Features Up
Create common component
for shared internal methods
 Fairly safe but can be a little harder to share

5/16/2016
40
Common Wisdom
“In almost all cases, I’m
opposed to setting aside time
for refactoring. In my view
refactoring is not an activity you
set aside time to do.
Refactoring is something
you do all the time in little
bursts.” — Martin Fowler
Work refactoring into your daily routine…
Refactoring: When to do it
‫۔‬ Regular refactorings make it fairly safe
and easy to do anytime. Especially when
you have good TESTS.
‫۔‬ When you are fixing bugs
‫۔‬ Adding new features
‫۔‬ Right after a release
‫۔‬ Might have to Refactor Tests too!!!

5/16/2016
41
Large Refactorings
 Four Big Refactorings
 Tease Apart Inheritance
 Convert Procedural Design to Objects
 Separate Domain from Presentation
 Extract Hierarchy
 Refactoring and Databases
 Architecture Smells
 Keeping the System Going
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

5/16/2016
42
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

5/16/2016
43
Sustaining
Architecture
What can be done to help sustain
our architecture in the long run?
Stuart Brand’s Shearing Layers
 Buildings are a set of components that
evolve in different timescales.
 Layers: site, structure, skin, services,
space plan, stuff. Each layer has its own
value, and speed of change (pace).
 Buildings adapt because
faster layers (services) are
not obstructed by slower
ones (structure).
—Stuart Brand, How Buildings Learn

5/16/2016
44
Yoder and Foote’s
Software Shearing Layers
“Factor your system so that artifacts that change at
similar rates are together.”—Foote & Yoder, Ball of
Mud, PLoPD4.
• The platform
• Infrastructure
• Data schema
• Standard frameworks, components, services
• Abstract classes and interfaces
• Classes
• Code
• Data
LayersSlower
Faster
Legacy Code
Definition:
- Code without tests, Code from last year, Code I didn’t write
The goal is to make small, relatively safe changes to get tests in
place, so that we can feel comfortable making larger changes
Take a stance - we will not let our code base get any worse
- New code does not have to go into class
as existing (untested) code
• Try to add new code, test driven, in new classes
• Sprout Method, Sprout Class
- Bugs are opportunities
• Identify the bug
• Write a failing test to expose the bug
• Fix the bug
• Test now passes

5/16/2016
45
Legacy Code
Change Algorithm
Identify change points
Find test points
Break dependencies
Write tests
Make changes
and refactor
Sprout Class/Method
 Sprout Class
 When adding a new feature to legacy
code, consider adding in its own class
 Can be Test Driven Developed
 Old code doesn’t get any worse
 Spout Method
 Instead of adding functionality by making
changes inline, add in a new method
 Develop method using TDD
 Legacy code doesn’t get any better,
but it doesn’t get any worse either

5/16/2016
46
Put a Rug at the Front Door
ALIAS: ENCAPSULATE AND IGNORE
KEEPING THE INTERNALS CLEAN
Patterns for
Sustaining Architecture
PLoP 2012 Paper
Wipe your Feet
at the Front Door
Filtering and Cleansing Sequence to keep
Place Order Interface Clean
Protected
Components
S1
S2
S3
Sn
Adapter/
Proxy/
Façade
Frontdoor
Wrapper
Filtering,
Cleansing,
Security
Checks
...

5/16/2016
47
Paving over the
Wagon Trail
ALIAS: MAKE REPETITIVE TASKS EASIER
STREAMLINING REPETITIVE CODE TASKS
Create simple examples, templates, & scripts
Develop a tool that generates code
Identify and use existing tools or frameworks
Develop a framework &/or runtime environment
Develop a domain-specific language
Patterns for Sustaining Architecture
PLoP 2012 Paper
95
Continuous Inspection
Asian PLoP 2014 Paper
CODE SMELL DETECTION
METRICS (TEST COVERAGE, CYCLOMATIC COMPLEXITY,
TECHNICAL DEBT, SIZES, …)
SECURITY CHECKS
ARCHITECTURAL
CONFORMANCE
AUTOMATE WHERE
YOU CAN!!!

5/16/2016
48
Legacy Discussion
Discuss some legacy
issues you have!
Let’s discuss some
alternatives to
help deal with it…
Thinking Fast vs. Slow
 Fast thinking:
decisions based on
intuition, biases,
ingrained patterns,
and emotions
 Slow thinking:
Reasoning, logical
thinking, contemplating

5/16/2016
49
Sustainable
Architecture
Stewardship
 Follow through
 Ongoing attention
 Not ignoring the little
things that can undermine
our ability to grow, change
and adapt our systems
Architectural Practice:
Reduce Technical Debt
 Integrate new learning
into your code
 Refactoring
 Redesign
 Rework
 Code clean up
 Unit tests
(functionality)
 Test for architectural
qualities (performance,
reliability,…)
100

5/16/2016
50
Agile Values Drive
Architectural Practices
 Do something. Don’t debate or
discuss architecture too long
 Do something that buys
you information
 Prove your architecture ideas
 Reduce risks
 Make it testable
 Prototype realistic scenarios
that answer specific questions
 Incrementally refine
your architecture
 Defer architectural decisions that
don’t need to be immediately made
Do
something!
Prove &
Refine
Indicators You’ve Paid Enough
Attention to Architecture
 Defects are localized
 Stable interfaces
 Consistency
 Developers can easily add
new functionality
 New functionality doesn’t
“break” existing architecture
 Few areas that developers avoid
because they are too difficult to work in
 Able to incrementally integrate new functionality

5/16/2016
51
Other Techniques for
Improving Quality
Steve McConnell
http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/
Average is 40% for
any one technique!
Combining
techniques
gives you
quality (> 90%)
Agile Mindset
Be Agile

5/16/2016
52
Dogmatic
Pragmatic
Synonyms: bullheaded, dictative,
doctrinaire, fanatical, intolerant
Antonyms: amenable, flexible,
manageable
Synonyms: common, commonsense,
logical, practical, rational,
realistic, sensible
Antonyms: idealistic, unrealistic
Being Pragmatic
No Planning
No Design
or Architecture
Sometimes
called Agile

Lot’s of
Upfront
Planning
Lot of Design
& Architecture
Traditional
or Waterfall

Rough
Adaptive
Plan (changing)
Right Balance
of Design
& Architecture
Being Agile

Balance Between…

5/16/2016
53
Draining the Swamp
You can escape from the
“Spaghetti Code Jungle”
Indeed you can transform the landscape.
The key is not some magic bullet, but a
long-term commitment to architecture,
and to cultivating and refining “quality”
artifacts for your domain (Refactoring)!
Patterns of the best practices can help!!!
Silver Buckshot
There are no silver bullets
…Fred Brooks
But maybe some silver buckshot
…promising attacks
Good Design
Frameworks
Patterns
Architecture
Process/Organization
Tools and Support
Refactoring
Good People ***

5/16/2016
54
So There is Some Hope!!!
Testing (TDD), Refactoring, Regular
Feedback, Patterns, More Eyes, …
Good People!!!
Continuous attention to technical excellence!
Retrospectives! Face-To-Face conversations.
Diligence and Hard Work!
Motivated individuals with the environment
and support they need.
But, Maybe Mud is why we have Agile…
Resources
 Agile Myths: www.agilemyths.com
 The Refactory: www.refactory.com
 Joe’s website: www.joeyoder.com
 TeamsThatInnovate:
www.teamsthatinnovate.com
 Pragmatic TDD :
 refactory.com/training/test-driven-development
 http://adaptiveobjectmodel.com/2012/01/
what-is-pragmatic-tdd/
 Being Agile at Quality blog:
 www.adaptiveobjectmodel.com/2015/04/
qa-to-aq-shifting-towards-agile-quality

5/16/2016
55
Thanks … Obrigado!!!
joe@refactory.com
Twitter: @metayoda

Dextra mud-sustaining architecture withrefactoring

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Dextra mud-sustaining architecture withrefactoring

Semelhante a Dextra mud-sustaining architecture withrefactoring (20)

Mais de Dextra

Mais de Dextra (20)

Último

Último (20)

Dextra mud-sustaining architecture withrefactoring