Your SlideShare is downloading. ×
0
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
BDD: What's in it for me?
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

BDD: What's in it for me?

4,404

Published on

Behaviour Driven Development and some of the benefits it offers for developers, customers and testers. …

Behaviour Driven Development and some of the benefits it offers for developers, customers and testers.

Originally presented at Skills Matter:

http://skillsmatter.com/event/agile-testing/bdd-whats-in-it-for-me

Published in: Technology, Design
2 Comments
15 Likes
Statistics
Notes
No Downloads
Views
Total Views
4,404
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
221
Comments
2
Likes
15
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • briefly introduce BDD
    benefits for particular roles on team
    experiences
    demo cucumber, a BDD tool
    ask questions but I'll keep the presentation moving
    q time at the end
  • from Melbourne, Australia
    agile for over 3 years
    mainly in XP teams as a developer
    doing BDD like things for a while
    trying to practise BDD for about a year

    collaboration aspect interests me most
  • who describes themselves as a customer?
    product owner? business analyst?
    I’m calling you a customer
    you want something
    paying the bills
    you accept the system

    who is a developer?
    you are building the thing
    you may have used Test Driven Development
    ... Domain Driven Design
    ... unit testing
    ... automated acceptance testing

    who is a tester?
    QA?
    you make sure it works
    you also think about ways it can work better

    BDD offers things that should make all of you happy
    some things are of interest to particular roles
  • who describes themselves as a customer?
    product owner? business analyst?
    I’m calling you a customer
    you want something
    paying the bills
    you accept the system

    who is a developer?
    you are building the thing
    you may have used Test Driven Development
    ... Domain Driven Design
    ... unit testing
    ... automated acceptance testing

    who is a tester?
    QA?
    you make sure it works
    you also think about ways it can work better

    BDD offers things that should make all of you happy
    some things are of interest to particular roles
  • who describes themselves as a customer?
    product owner? business analyst?
    I’m calling you a customer
    you want something
    paying the bills
    you accept the system

    who is a developer?
    you are building the thing
    you may have used Test Driven Development
    ... Domain Driven Design
    ... unit testing
    ... automated acceptance testing

    who is a tester?
    QA?
    you make sure it works
    you also think about ways it can work better

    BDD offers things that should make all of you happy
    some things are of interest to particular roles
  • heard about BDD before?
    experimenting? used before?

    simple definition: BDD == blend of goodies from DDD and TDD

    DDD
    Domain Driven Design
    conceptual model of the problem domain
    manages complexity and change in software
    we make the software model the problem
    we use the same language to describe:
    things
    behaviour
    ubiquitous language - ubiq = everywhere at once
    finding + changing things should be relatively easy
    some technical guidelines
    mainly theoretical
    DDD can be used by everyone

    TDD
    Test Driven Development
    designing code using automated behavioural tests
    write tests for behaviour
    run the tests - they break
    enough code to make the test pass
    pick the next thing
    this means we only develop as much as we need
    byproduct: nice test suite
    used to design interactions
    not terribly visible to anyone who isn't a dev
    but the results are

    BDD
    Behaviour Driven Development combines best aspects of both of these things
    test driven practises applied to WHOLE behaviour of the system
    move the design practises of TDD outside further
    encourages communication and collaboration
  • guiding principles of BDD
    these principles drive how you practise it

    its all behaviour
    strong focus on behaviour
    our code, tests/specs talk in terms of behaviour
    we don't talk about Calculator object passing 1 and 2 to the addition method
    we talk about Calculator adding
    retain and strengthen the link with the problem we are solving
    constantly focussed on it
    ubiquitous language - no translation

    deliver stakeholder value
    agree that we should only do things that create value?
    we should generally do the most valuable first?
    sure we do
    hard thing is figuring out whether they do or not
    question rigorously the value something is creating
    prioritise it against other things
    build only the things that are important
    build the most important first

    enough is enough
    only build what you need to build
    plan as much as you need to
    START building ASAP
    STOP building ASAP
  • DDD influence
    ubiquitous language one of the most beneficial parts
    ubiquitous == everywhere at once
    talk the same language about the thing we’re building
    about behaviour
    same problem, same system, same language

    becomes easier to communicate
    maximise our chances of building the right thing

    what threatens to prevent this from happening?

    multiple representations of the same behaviour
  • seen this in a number of projects

    customer has a story about a new feature
    purest form of the behaviour
    (hopefully) not polluted with any technical jargon
    everyone should be able to understand this

    stored in a wiki, issue management system like JIRA, Pivotal tracker
    some, I hear, even store it in a Microsoft Word document

    at the best, at least everyone can read or change this
    at the worst, its kept locked away
    only a select few can change it

    this is ONE representation of the system's desired behaviour
  • developer starts to work on the feature
    must represent the problem in code
    if they are practising DDD then they strive to maintain ubiquitous language in the code
    unfortunately, this guy hasn't

    hopefully also create automated tests, regardless of ubiq language
    these basically act as a safety net to make sure nothing is broken

    this is ANOTHER representation of the system's desired behaviour
  • testing time
    tester needs to double check that each scenario passes

    everyone has seen something like this? a procedural test?

    mix of business domain and technical terms

    they may be working from a manual test script
    or maintain their own automated tests

    this is YET ANOTHER representation
  • how does this look?
    3 representations of the same behaviour
    3 roles trying to communicate about the ONE thing
    the one system

    a customer states what they want in plain language
    "market research, could be a untapped market in an automatic bill totaller”
    totalling scenario

    a developer takes this, uses their own version of language
    tester takes it, represents it as a procedural test
    developer finishes
    feature goes into test
    tester tests
    "I added money to the bill as per steps 2 and 3 but the sum was wrong”
    “it was 20 pounds"
    dev - "bill? oh the cheque. that'll take a while to fix"
    speak to customer - "when we summed the cheque it was wrong"
    customer - "?”, you mean totalled the bill
    and around it goes until everyone is on the same page
    repeat at least once per bug or issue that comes up
  • divergence reinforced by 3 representations

    the worst situation I have seen for this:

    story descriptions in JIRA
    devs automated scenarios using selenium and JUnit
    testers automated using QTP
    of 3, selenium tests only thing updated properly
    changed in line with the code
    JIRA neglected - no apparent value in updating
    QTP ran nightly, broke every second day, eventually dropped

    how do we fix this?
  • ubiquitous language
    a good chunky, woody sounding word
    same thing, same language

    ONE representation of behaviour
    lessens the chance for language to diverge

    language is shared
    we develop it together

    how do we achieve it?

    discussion, not just the problem but vocab.
    model the problem
    flush out new things

    build understanding of the problem together
    more we understand, better we can model it in code
    better we model it in code, easier it is to change

    story kickoff process

    nut out scenarios and wording as a group
    (devs, customer, testers)

    standard scenario format = Given, When, Then
    Given == starting state
    When == stimulus that changes something
    clicking a button or whatever
    Then == the state we expect after

    doing this together...
    improves the quality of our description of behaviour
    cements everyone's understanding of the problem
    irons out inconsistencies in language

    shared language and understanding
    == more effective communication
    == more maintainable systems
  • main benefit of BDD

    better communication and collaboration
    we create a shared understanding of the problem
    we find it easier to talk about the system

    we should all be on the same page
  • all agree, only build things that are valuable?
    value + cost helps us decide when we build
    or if we build at all

    how do you know when something is valuable?
    need to ask a lot of questions
  • dig for value

    write features together as a team
    act of writing a feature
    == uncovering why it is valuable
    == uncovering how valuable it is

    one tool you can use to uncover value is popping the why stack
    term originally attributed to Luke Barrett at Thoughtworks
    related to the 5 whys root cause analysis

    Stop when you get to:

    # Protect revenue
    # Increase revenue
    # Manage cost

    if you can't get there then why are you playing the feature?
    maybe you've dug up an old shoe instead of treasure
    ditching a feature is a great feeling

    "in order to" is very important - spend time on analysing it
  • reducing waste
    build the most important things first
    chuck others out completely

    should be able to trace each feature back to the strategic purpose of the project
    if you haven't got one of those then you have bigger problems
  • also about avoiding waste
    do the bare minimum
    again, sounds like common sense?

    how do we know when to stop?
    when are we done?
  • when do I stop?

    who has heard of red, green, refactor?
    TDD mantra
    simpifies things, breaks things down into simple steps
    do the bare minimum
    also gives you a place to start, first broken test

    describe process, practical example next

    to implement a feature:
    pick first pending (yellow) scenario
    pick first pending step
    step is pending if it hasn't yet been implemented
    step breaks once implemented
    make sure your step is doing its job, need the red
    behaviour is not implemented yet
    make it pass
    build only the functionality needed
    refactor if necessary, stays green
    repeat for each step
    scenario goes green
    repeat for next pending scenario
    all scenarios passing == feature is passing

    done when all scenarios pass
    none of the previous ones are broken
    may need to add or change scenarios as you go
  • quick demo of cucumber
    show what I'm talking about when I mention features and steps
    we are going to build the bill totalling feature
  • reiterate

    helps you know "are we there yet?"
    isn't foolproof
    BUT forces you to continually ask, are we there yet
    the features say we’re there, are we really?
    do we need more scenarios?
  • everyone recognise the process we followed?

    where to START
    what to do NEXT
    when to STOP

    even when "done", there may be more scenarios to discover
    a guideline but a good one
  • when can we start building stuff?
    when we have enough information to start

    code is what matters
    you need to do some planning, design
    only need to do so much

    has anyone heard of bare sufficiency?
    normally applied to software dev methodologies
    says it should be just sufficient to get the job done
    possibly with some gaps
    they get filled in as we build

    how we'd flesh out a feature:
    planning for next iteration
    enough detail to the level required at the time
    to be able to estimate
    keep it as bare as possible
    cover enough scenarios to estimate
    scenarios
    assumptions
    estimate
    may result in other stories being created
    also spikes
    file it away - normally done on a printing whiteboard

    when the story was kicked off we'd review the feature
    go over it again, see if we had learnt anything in the meantime
    adjust or add new scenarios
    make sure the size was the same
    when we had enough to start, we’d just start
    new scenarios would come in later
    often as a result implementing the initial ones
  • get to a point where you can build it
    a working system gives you valuable feedback:
    how will it work?
    how could it work better?
    will it work at all?

    anyone had devs waiting on analysis to be done before they can start?
    analyse together to remove that bottleneck
    tight feedback about whether you have analysed enough

    just build it
    your understanding grows as you have something to play with

    generates more knowledge
    generates more questions about how it should work
  • questions are valuable
    they help grow knowledge of the feature

    everyone is responsible for asking questions
    a tester or QA specialises in this
    they will be the ones asking most of these questions

    a question may be "why doesn't it work like expected" - a bug
    a question may also be "should we expect it to work like this?" - change to a feature
    a question is not necessarily a bug

    lots of questions == good
    better quality product

    questions lead to more questions
    exploring the feature leads to more being raised
    this flattens off at the end as potential questions are exhausted
    there is a very juicy curve in the middle

    we can’t uncover all questions
    uncover as many as we can
  • we all need to ask questions
    testing == really driving them out
    testing window is the “quality time” between tester and system
    more time spent == more questions asked

    here we uncover 2 questions during the window
  • doubling our window leads to uncovering 4x questions
    bigger window == more coverage of juicy part of curve
    we want to maximise our chance of hitting that flat spot
    we can all agree that this is a good thing?

    otherwise we risk things being discovered later
    like in production

    this doesn't always work out though
  • who has used a story wall before?
    tracks flow of work between different stages
    ready for dev, in dev and in test then DONE

    who has seen this on the second last day?
    who can tell me what is wrong with this one?

    pile everything onto the testers on the last day of iteration

    start testing earlier
    regulate the flow of work
    avoid testing being the bottleneck

    BDD facilitates this
    gives feedback on which scenarios are done
    they can then be tested
    we work on one scenario at a time
    when it is passing we should be able to let the testers at it

    previous project:
    demo a scenario to a tester as soon as it was done
    they would often dig things up immediately

    the test stage became a final check
    the bulk of the scenarios had been verified earlier

    move start of testing window earlier
    maximise it, maximise chance of exhausting questions
  • exploring early leads to more questions being asked
    higher quality

    everyone gets earlier feedback about bugs
    potential new scenarios and changes

    how else can we free up time for exploring?
  • useful byproducts

    bran is a useful byproduct of processing cereals
    we are really interested in refined grains
    but bran is still terribly terribly useful

    we have a similar situation with BDD

    discovering and implementing behaviour byproduct == automated tests
    automated tests are an awesome byproduct of BDD
    these tests are like bran: they're great stuff, we love them
    BUT discovering and implementing behaviour is our primary focus

    but the fact remains; automated tests are a great byproduct
  • byproduct is automated test suite

    who is familar with unit testing/automated testing?

    tightrope metaphor:
    making changes to code is like walking a tightrope
    automated tests are a safety net that tell us when we have broken something

    if we have no safety net we walk very, very slow
    if we have a safety net we can move a lot faster
    we know that if we fall, we'll be safe
    we have more confidence to try new tricks

    automated tests act like a safety net around the code

    anyone had something fail in the app but "the unit test passes?"
    move the safety net out further in the layers of the application
    when we add or change behaviour, we MUST keep our automated tests green

    more chance of catching things
  • automated tests are great
    having automated tests that describe behaviour is even better

    developers using automated tests should be able to see the benefit of this

    is this interesting to testers?
  • testers:
    who uses manual regression testing in their team?
    who likes it?

    manual regression testing can eat a lot of time and resources
    cost grows exponentially with:
    the size of the system
    number of releases
    rely on frequent releases to make things work; they must be cheap

    would it not be awesome to have testers do less manual regression testing?

    need to look at how we can make this work
  • this is not strictly part of BDD
    a way to get more benefit out of automated testing
    Cucumber model

    shared ownership

    everyone owns features
    they encode our shared understanding of the behaviour
    both developers and testers need to own the step defs
    need visibility if they are going to be asked to rely on them
    how do they know what is covered?
    how do they know how it is covered?

    need to be able to work on them with developers

    testers need more programming skills
    devs need more testing skills
    hopefully working together will achieve this

    I haven't yet seen this really work properly on a team
    I would very much like to
  • what if we do get this to work?

    regression testing time is freed up for exploratory testing
    doesn't replace manual regression testing but should reduce it greatly
    increases testing window
    increase the number of questions

    regression testing becomes cheaper and faster
  • specifications
    specifications document how the system should behave

    people like to know how their system behaves
    especially as it grows bigger
    we used to rely on written specifications for this
    you'd update them when you change the code, right?
    packed away in a warehouse like the lost ark
    out of sight == out of mind
    it becomes dead information
    its connection with the system is severed and it dies
    the document becomes useless

    the place I was working did not like this
    provided more confusion than information
    this is one of the reasons they became interested in Cucumber and BDD
  • a BDD feature is "live" information
    specification is executable
    you can see if it still describes how the system actually behaves
    if you use continuous integration, you can make it a part of your build
    in fact, you should

    executable specs retain their relationship to the system that they describe

    you need to put a lot of effort into style
    you need to make sure that generated documentation makes sense
    best way is to get customers into habit of using it

    you should look at this generated documentation regularly
    make sure it it good enough for your customer, if it isn't then fix it
    you probably aren't specifying behaviour well enough

    this is Cucumber output
    rspec and other frameworks can also output nice content like this
  • documentation on demand

    tools like Cucumber, Rspec and others have ability
    use it; generate reports from your latest build

    tells you two things:
    what the system should do under certain scenarios
    what the system actually does under these scenarios (green steps/examples)

    don't try and keep documents in synch - it just doesn't work

    if the format doesn’t suit, change it
    write a custom formatter
    ensure it can be used as the documentation for the system
  • a better understanding of the problem
    this is by far and beyond the big one

    a better chance of getting what I really need
    more efficient development
    quicker feedback
    live behavioural documentation
  • knowing where to start, what to do next and when to finish
    awesome, TDD-like flow
    the chance to start building something earlier
    safety net when I’m making changes
    more confidence when making changes
  • more time to explore
    automate regression testing as much as possible
    something to explore earlier
    guidelines for which scenarios can be tested
    also means we tend to work on one scenario at a time
  • sounds pretty good right?
    it will not solve all of your problems

    this is what can happen when you do it well
    closer you get the more you should start seeing benefits

    I've presented a lot of positive things here
    it may seem a bit idealistic
    like most agile approaches, the main negative == hard to implement properly
    requires more thought and communication than traditional methods
    need to be committed to continual improvement

    BDD is not about tools
    it is about communication and collaboration
    this is what allows you to make better software
    BDD just facilitates that
  • Transcript

    • 1. Behaviour Driven Development what’s in it for me? Brent Snook Thursday, 15 October 2009
    • 2. Brent who? • from Melbourne, Australia • self confessed Agile weenie • working with BDD for about a year • available for dev, coaching, children’s parties • fuglylogic.com • brentsnook Thursday, 15 October 2009
    • 3. Audience Thursday, 15 October 2009
    • 4. Audience Customer Thursday, 15 October 2009
    • 5. Audience Customer Developer Thursday, 15 October 2009
    • 6. Audience Customer Developer Tester Thursday, 15 October 2009
    • 7. BDD ≈ DDD + TDD Thursday, 15 October 2009
    • 8. Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
    • 9. Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
    • 10. In order to speed billing As a waiter I want to calculate bill total story descriptions (JIRA,Wiki,Word) Thursday, 15 October 2009
    • 11. cheque.sum .should == 12.0 automated unit and acceptance tests Thursday, 15 October 2009
    • 12. 1. Add £2.00 to bill 2. Add £10.00 to bill 3. Verify sum is £12.00 test procedures Thursday, 15 October 2009
    • 13. Translation Thursday, 15 October 2009
    • 14. Translation Thursday, 15 October 2009
    • 15. DO Translation NOT WANT!! Thursday, 15 October 2009
    • 16. Mmmmm.....Ubiquitous Given an empty bill When I add £2.00 And I add £10.00 Then the total is £12.00 Thursday, 15 October 2009
    • 17. Speak the Same Language We can understand each other. We are more likely to gain a deeper insight of the problem. We have a better chance of building the right thing. Cool bananas! Thursday, 15 October 2009
    • 18. Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
    • 19. Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
    • 20. In order to ... speed up billing ... why? so that billing is cheaper ... why? so that I can manage cost DING! Thursday, 15 October 2009
    • 21. Reduce Waste I waste less time and money building things that aren't really needed and uncovering value helps me to prioritise properly. Fantabulous! Thursday, 15 October 2009
    • 22. Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
    • 23. Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
    • 24. Are We There Yet? Scenario Step Thursday, 15 October 2009
    • 25. Demo Thursday, 15 October 2009
    • 26. Are We There Yet? Scenario Step Thursday, 15 October 2009
    • 27. A Place to Start, A Place to Stop Knowing where to start, what to do next and when to stop. Bonza! And less superfluous stuff! Thursday, 15 October 2009
    • 28. (Barely) Sufficient Detail Scenario: Simple bill total Given an empty bill When I add 2 pounds And I add 10 pounds Then the total is 12 pounds Thursday, 15 October 2009
    • 29. Just Build It I can start building something as soon as possible. Grouse! Something to play with earlier! Thursday, 15 October 2009
    • 30. Questions Asked 12 12 11 Total Questions 8 4 2 Time Thursday, 15 October 2009
    • 31. Questions Asked Testing window 12 12 11 Total Questions 8 4 2 Time Thursday, 15 October 2009
    • 32. Questions Asked Testing window 12 12 11 Total Questions 8 4 2 Time Thursday, 15 October 2009
    • 33. Spread the Load 2 DAYS LEFT !!! Ready Dev Test Done Thursday, 15 October 2009
    • 34. Explore Early Less chance of getting swamped and I get to uncover more problems. O' Frabjous day! Bugs and new scenarios earlier! Thursday, 15 October 2009
    • 35. Useful Byproducts Thursday, 15 October 2009
    • 36. Safety Net Thursday, 15 October 2009
    • 37. Automated Tests I can make changes with greater confidence and speed. W00t! Hmm...could I use those? Thursday, 15 October 2009
    • 38. Manual Regression Testing Thursday, 15 October 2009
    • 39. Shared Ownership Step Definitions Feature Thursday, 15 October 2009
    • 40. Automated Regression Suite I can focus more on exploratory testing. Zipidee do da! Regression testing is cheaper and faster. Thursday, 15 October 2009
    • 41. Dead Specifications Here Lies Total Bill Slipped away Out of sight Out of mind Won’t be remembered Thursday, 15 October 2009
    • 42. Live Specifications Feature: Total a bill In order to speed billing As a waiter I want to calculate bill total Scenario: Simple bill with two items Given an empty bill When I add 2 pounds And I add 10 pounds Then the bill total will be 12 pounds Scenario: Remove item from bill Given an bill totalling 20 pounds When I remove 4 pounds Then the bill total will be 16 pounds Thursday, 15 October 2009
    • 43. Documentation on Demand A comprehensive description of how my system should and does behave? On demand?! Splendiferous! Handy for verifying behaviour too. Thursday, 15 October 2009
    • 44. What’s in it for me? • better understanding of the problem • a better chance of getting what I really need • more efficient development • quicker feedback • live behavioural documentation Thursday, 15 October 2009
    • 45. What’s in it for me? • better understanding of the problem • knowing where to start, what to do next and when to finish • the chance to start building something earlier • safety net when I’m making changes Thursday, 15 October 2009
    • 46. What’s in it for me? • better understanding of the problem • more time to explore • something to explore earlier Thursday, 15 October 2009
    • 47. Whoah There! Thursday, 15 October 2009
    • 48. Questions? • brent@fuglylogic.com • brentsnook • pub Thursday, 15 October 2009
    • 49. Links • http://skillsmatter.com/podcast/agile-testing/bdd- whats-in-it-for-me • http://behaviour-driven.org/ • http://dannorth.net/whats-in-a-story • http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd • http://en.wikipedia.org/wiki/5_Whys • http://pragprog.com/titles/achbd/the-rspec-book • http://www.infoq.com/minibooks/domain-driven-design-quickly • http://cukes.info • http://alistair.cockburn.us/Balancing+lightness+with+sufficiency Thursday, 15 October 2009
    • 50. Images/Fonts • Blender - http://www.flickr.com/photos/lintmachine/2987986325 • Steering Wheel - http://www.flickr.com/photos/wheatfields/290438580 • Drinky Bird - http://www.flickr.com/photos/sfmike22/2326128380/ • Post It Note - http://www.flickr.com/photos/flatcat/3555774083/ • Digging for Treasure - http://www.flickr.com/photos/wessexarchaeology/51568417/ • Table Setting and Napkin - http://www.flickr.com/photos/sifu_renka/2789833722/ • Gravestone - http://www.flickr.com/photos/36041246@N00/3419197777/ • Bran - http://www.flickr.com/photos/trekkyandy/3316748814 • Tightrope - http://www.flickr.com/photos/marquette/1812518264/ • Repeat Icon - http://www.iconarchive.com/show/aesthetica-2-icons-by-dryicons/repeat-icon.html • Silver Bullet - http://www.flickr.com/photos/annguyenphotography/3268547290 • “No” Sign - http://commons.wikimedia.org/wiki/File:No_sign.svg • Avatar Editor - http://myavatareditor.com/ • Whiteboard Font - http://callsignkatejones.deviantart.com/art/House-Whiteboard-font-64929545 • Napkin Font - http://www.1001fonts.com/font_details.html?font_id=2178 Thursday, 15 October 2009

    ×