AgilePT'10 - Evolving Software: Five powerful metaphors to explain change

Evolving Software
Five powerful metaphors to explain change

Agile Portugal 2010 • Filipe Figueiredo Correia • filipe.correia@fe.up.pt
FEUP / ParadigmaXis

Metaphors
● Human thought is fundamentally
metaphorical
● Metaphors: understanding concepts in
terms of another concepts!
● Metaphors hide some aspects and make
us focus on another

Metaphors
● Some examples
● Life is a container
– I've had a full life
– He's got an empty life
– There's not much left for him in life
– Get the most out of life
● Having control is up; being subject to control is down
– I am on top of the situation
– His in a high command
– I am under his control
– His power is on the decline

from “Metaphors We Live By” by George Lakoff and Mark Johnson

Metaphors in Software Development
● Metaphors are pervasive in software
development
● They are a primary tool for thought
● But also priceless to explain non-trivial
ideas!

Metaphors in Software Development
● This presentation is about “responding to
change”
● We will look at five software evolution
metaphors:
● Learning to Drive
● Software Aging
● Technical Debt
● Code Smell
● Big Ball of Mud

Metaphors and the Agile Movement
● eXtreme Programming practice: "System
Metaphor"
“the software project is guided by a single
overarching metaphor that describes how the
whole system works”
● But, to find “a single overarching
metaphor” is usually very difficult!

Metaphors and the Agile Movement
● More often developers use a set of
smaller metaphors to describe specific
parts of the system
● E.g., Most Design Patterns have a
metaphorical name:
● Observer
● Singleton
● Visitor
● ...

Learning to Drive

http://www.flickr.com/photos/terwilliger911/473246309/

Learning to Drive

“Driving is about constantly paying attention,
making a little correction this way, a little
correction that way”
Kent Beck's mother

http://www.flickr.com/photos/terwilliger911/473246309/

Learning to Drive
● Kent Beck
Book: eXtreme Programming Explained – Embrace Change. Addison-Wesley

● Metaphor of driving a car
● Costumers drive the domain understanding
● The whole team drives the development process
● The paradigm of XP: Stay aware. Adapt. Change.
● Everything in software projects changes: business,
requirements, design, technology, the team itself!
● Change is inevitable. To cope with it, we must adapt.

Software Aging

http://www.flickr.com/photos/steffe/300053732/

Software Aging

●“Programs, like people, get old. We can't
prevent aging, but we can understand its
causes, take steps to limits its effects,
temporarily reverse some of the damage it
has caused, and prepare for the day when
the software is no longer viable”
David Parnas

http://www.flickr.com/photos/steffe/300053732/

Software Aging
● David Parnas
Paper: “Software Aging” ICSE 1994

● Sometimes referred to as “Decay”
● Human life metaphor
● Like people, software loses some of its capabilities
with time
● The alternative to aging is death. Software aging
happens to all successful products!
● Constantly updating software to new user needs
will decrease the effects of age. Of course,
“congenital illnesses” may also exist...

Technical Debt

http://www.flickr.com/photos/daviddmuir/2125697998/

Technical Debt

● “Shipping first time code is like
going into debt”
Ward Cunnigham

http://www.flickr.com/photos/daviddmuir/2125697998/

Technical Debt
● Ward Cunningham
Experience report: “The WyCash portfolio management system” OOPSLA 1992

● Financial metaphor
● It's like paying interest on a loan:
– Borrowed money allows to do something sooner
– But you'll be paying interest until you pay it back
● Can you borrow money and never pay it back? That's what is
frequently tried in software development... but:
– You may reach a point when you lose all your purchasing power, and
all you do is pay interest
● Emphasis on the technical aspects. E.g., We are not
talking about how many requirements are implemented

Technical Debt
● Misconceptions clarified...
● Debt is writing code that doesn't reflect your
current understanding
● It is not the same as writing code poorly!
● Debt is a good idea! Using the debt metaphor
will work in your advantage if you refactor
– Rapid delivery of value
– Time-to-market...

Code Smell

http://www.flickr.com/photos/19779889@N00/460032282/

Code Smell

● “Highly experienced and knowledgeable
developers have a 'feel' for good design”

c2.com


Code Smell
● Kent Beck
@ c2.com: http://xp.c2.com/OnceAndOnlyOnce.html and http://xp.c2.com/CodeSmell.html

● Metaphor of the human sense of smell
● Like when something smells badly, experienced developers
sense the code isn't quite right. They identify source-code
constructs that are correlated with a lacking implementation
● Like with an actual smell, you may not know what's its concrete
origin
● When something is smelling badly close to you, you may want to
take a closer look and find what is the cause
● A code smell is not a certainty that something should be
changed, it is only a hint

Big Ball of Mud


Big Ball of Mud

●“A BBoM is haphazardly structured,
sprawling, sloppy, duct-tape and bailing wire,
spaghetti code jungle.”
Brian Foote & Joe Yoder


Big Ball of Mud
● Brian Foote and Joseph Yoder
Paper: “Big Ball of Mud” PLoP 1999

● Also known as spaghetti code
● Metaphor of a formless and tightly coupled mass
● “Unregulated growth, and repeated, expedient repair”
● “Real mud” may keep together as a randomly cohesive
and formless volume. Code may also lack form (design)
● “Real mud” gets people dirty. Muddy code is complex code,
the options taken to maintain it frequently feel sub-optimal.

Concluding...
● Metaphors are priceless to explain non-trivial ideas!
Explaining someone the principles of adaptation to changing
requirements?
● Technical debt; Big Ball of Mud
Explaining someone in your project the consequences of not
refactoring?
● Aging
Explaining the difficulties of maintaining a legacy system?
● Code Smell
Explaining someone why should they refactor in a
particular case?

Concluding...
● Metaphors allows you to quickly reuse a set
of constraints, that leads you to think a
certain way... but those constraints may not
match reality completely
● “Argument is war” works in some ways and fails
in another ways
– Argumentation strategy / line of attack / win the
argument / …
● Beware the use of weak metaphors to elude
others... (i.e., intellectual impostures)

Questions?

Filipe Figueiredo Correia
FEUP / ParadigmaXis
filipe.correia@fe.up.pt

2010 . 06 . 26

References
● Metaphors We Live By
George Lakoff and Mark Johnson

● Software Metaphor Google Group
Managed by Joshua Kerievsky
http://groups.google.com/group/softwaremetaphor/

● The metaphors:
eXtreme Programming Explained – Embrace Change. Kent Beck. Addison-Wesley. 1999
● Software Aging (decay)
Software aging. David Parnas. ICSE. 1994
● Technical Debt.
Experience report: “The WyCash portfolio management system” OOPSLA 1992. Ward Cunningham
http://www.c2.com/cgi/wiki?TechnicalDebt

● Code smell
c2.com. Kent Beck
http://www.c2.com/cgi/wiki?CodeSmell

● Big Ball of Mud
PloP 1997. Brian Foote and Joseph Yoder

AgilePT'10 - Evolving Software: Five powerful metaphors to explain change

More Related Content

Viewers also liked (11)

Similar to AgilePT'10 - Evolving Software: Five powerful metaphors to explain change (20)

Recently uploaded (20)

AgilePT'10 - Evolving Software: Five powerful metaphors to explain change