• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
AgilePT'10 - Evolving Software: Five powerful metaphors to explain change
 

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

on

  • 4,381 views

One of the four values of Agile Software Development is “responding to change”, an area which is particularly fruitful in metaphors. This presentation looks at five metaphors for software ...

One of the four values of Agile Software Development is “responding to change”, an area which is particularly fruitful in metaphors. This presentation looks at five metaphors for software evolution, and how they relate to each other: “Learning to Drive”, “Software Decay”, “Technical Debt”, “Code Smell” and “Big Ball of Mud”. We will discuss the role that metaphors play in software development, their benefits and eventual liabilities.

Statistics

Views

Total Views
4,381
Views on SlideShare
4,361
Embed Views
20

Actions

Likes
0
Downloads
24
Comments
0

2 Embeds 20

http://2010.agilept.org 11
http://www.agilept.org 9

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • 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...
    • Software Aging
    • 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
    • Technical Debt
    • Technical Debt
    • Technical Debt
    • 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 http://www.flickr.com/photos/19779889@N00/460032282/
    • 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 http://www.flickr.com/photos/19779889@N00/460032282/
    • Big Ball of Mud ●“A BBoM is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle.” Brian Foote & Joe Yoder http://www.flickr.com/photos/19779889@N00/460032282/
    • 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! ● Learning to Drive 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: ● 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 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