Evolving SoftwareFive powerful metaphors to explain change
Agile Portugal 2010 • Filipe Figueiredo Correia • [email protected] FEUP / ParadigmaXis
MetaphorsMetaphors
● Human thought is fundamentally metaphorical
● Metaphors: understanding concepts in terms of another concepts!
● Metaphors hide some aspects and make us focus on another
MetaphorsMetaphors
● 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 DevelopmentMetaphors 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 DevelopmentMetaphors 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 MovementMetaphors 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 MovementMetaphors 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 DriveLearning to Drive
http://www.flickr.com/photos/terwilliger911/473246309/
Learning to DriveLearning to Drive
http://www.flickr.com/photos/terwilliger911/473246309/
“Driving is about constantly paying attention, making a little correction this way, a little
correction that way”
Kent Beck's mother
Learning to DriveLearning to Drive
● Kent BeckBook: 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 AgingSoftware Aging
http://www.flickr.com/photos/steffe/300053732/
Software AgingSoftware Aging
http://www.flickr.com/photos/steffe/300053732/
● “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
Software AgingSoftware Aging
● David ParnasPaper: “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...
Software AgingSoftware Aging
Technical DebtTechnical Debt
http://www.flickr.com/photos/daviddmuir/2125697998/
Technical DebtTechnical Debt
http://www.flickr.com/photos/daviddmuir/2125697998/
● “Shipping first time code is like going into debt”
Ward Cunnigham
Technical DebtTechnical Debt
● Ward CunninghamExperience 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 DebtTechnical Debt
Technical DebtTechnical Debt
Technical DebtTechnical Debt
Technical DebtTechnical Debt
Technical DebtTechnical 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 SmellCode Smell
http://www.flickr.com/photos/19779889@N00/460032282/
Code SmellCode Smell
http://www.flickr.com/photos/19779889@N00/460032282/
● “Highly experienced and knowledgeable developers have a 'feel' for good design”
c2.com
Code SmellCode 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 MudBig Ball of Mud
http://www.flickr.com/photos/19779889@N00/460032282/
Big Ball of MudBig Ball of Mud
http://www.flickr.com/photos/19779889@N00/460032282/
● “A BBoM is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire,
spaghetti code jungle.”
Brian Foote & Joe Yoder
Big Ball of MudBig Ball of Mud
● Brian Foote and Joseph YoderPaper: “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...Concluding...
● Metaphors are priceless to explain non-trivial ideas!● Learning to Drive
Explaining someone the principles of adaptation to changing requirements?
● Technical debt; Big Ball of MudExplaining someone in your project the consequences of not refactoring?
● AgingExplaining the difficulties of maintaining a legacy system?
● Code SmellExplaining someone why should they refactor in a particular case?
Concluding...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)
ReferencesReferences
● Metaphors We Live ByGeorge Lakoff and Mark Johnson
● Software Metaphor Google GroupManaged by Joshua Kerievskyhttp://groups.google.com/group/softwaremetaphor/
● The metaphors:● Learning to Drive
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 Cunninghamhttp://www.c2.com/cgi/wiki?TechnicalDebt
● Code smell c2.com. Kent Beckhttp://www.c2.com/cgi/wiki?CodeSmell
● Big Ball of MudPloP 1997. Brian Foote and Joseph Yoder