Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Paying Technical Debt: A Top-Down Approach @Scd16

Paying Technical Debt: A Top-Down Approach @Scd16

Having developers do TDD and Agile places an enormous pressure on them, as TDD mindset is difficult to get accustomed to. Many people strongly dislike it when they first approach it like this, and there are better strategies to do that. Introducing some of the Agile practices (stories, sprints) in conjunction with BDD to an ongoing project enables developers to notice their mistakes early on and buys them on the testing side. After they get familiar with the approach, and feeling comfortable running test suites, it’s much easier to get the same people who initially were reluctant to TDD to embrace the bottom-up design emerging from unit tests.

Georgiana Gligor

May 20, 2016
Tweet

More Decks by Georgiana Gligor

Other Decks in Technology

Transcript

  1. PAYING TECHNICAL DEBT:
    A TOP-DOWN APPROACH
    SHOPWARE COMMUNITY DAY

    MAY 2016
    image source
    GEORGIANA GLIGOR

    TEKKIE CONSULTING

    View full-size slide

  2. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    Georgiana Gligor
    ✓ Geek. Mother. Do-er.
    ✓ Crafting LAMP enterprise-
    level apps since 2003
    ✓ Architecture and DevOps
    consultant
    ✓ PHP Cluj Meetup Organizer

    View full-size slide

  3. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    via Twitter

    View full-size slide

  4. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    Agenda
    ✓ What is technical debt?
    ✓ Team roles
    ✓ Bottom-up approach
    ✓ Top-down approach
    ✓ Getting things done

    View full-size slide

  5. TECHNICAL
    DEBT

    View full-size slide

  6. Shipping code
    first time code
    is like going
    into debt.
    Ward Cunningham

    View full-size slide

  7. A mess is not
    technical debt.
    Uncle Bob

    View full-size slide

  8. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    Technical Debt Quadrant
    source: Martin Fowler
    Reckless Prudent
    Deliberate
    Inadvertent
    “We don’t have time
    for design”
    “We must ship now
    and deal
    with consequences”
    “Now we know
    how we
    should have done it”
    “What’s Layering?”

    View full-size slide

  9. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    ✓ July 31st 2012
    ✓ lost everything in 45 minutes
    ✓ SMARS routing algorithm
    ✓ Power Peg functionality
    Knight Capital Group

    View full-size slide

  10. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    ✓ June 4th 1996
    ✓ losses: > $370 million
    ✓ guidance system shut down after 37s
    ✓ reused inertial reference platform
    Ariane 5

    View full-size slide

  11. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    Team Roles
    Role Mentality Approach Level
    project manager trace system
    UX / UI usable & nice user
    software engineer build (sub)system
    tester break system
    DevOps maintain system

    View full-size slide

  12. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    Team Distribution
    developers
    UX / UI
    testers
    managers
    DevOps

    View full-size slide

  13. THE BOTTOM-UP
    APPROACH

    View full-size slide

  14. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    ✓ requires discipline
    ✓ tests cross the boundary of a single class
    ✓ collaborators: dummies / stubs / mocks
    ✓ dependencies can be slow
    ✓ tests become slow as they grow
    ✓ refactoring => removing unit tests
    TDD

    View full-size slide

  15. “REAL PROGRAMMERS
    DON’T TEST”

    View full-size slide

  16. My code works.
    I have a great track
    record.
    Why start now?
    Reason #1

    View full-size slide

  17. I am just making a
    small cosmetic
    change, nothing can
    go wrong.
    Reason #2

    View full-size slide

  18. Our client requested
    this functionality live
    by next Monday. We
    are short of time.
    Reason #3

    View full-size slide

  19. Client only pays for
    working software.
    Programmers are
    expensive, we can’t
    possibly sell this work.
    Reason #4

    View full-size slide

  20. We’re using V-Model
    approach. We’re not
    stepping on the
    dedicated QA team’s
    toes.
    Reason #5

    View full-size slide

  21. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    V-Model
    source: PA Consulting Group case study

    View full-size slide

  22. TESTING
    CONCEPTS

    View full-size slide

  23. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    ✓ Release acceptance testing (RAT) / smoke testing
    ✓ Functional acceptance simple testing (FAST)
    ✓ Compliance acceptance testing
    ✓ Deployment acceptance testing
    Acceptance Testing

    View full-size slide

  24. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    ✓ Task-oriented functional tests (TOFTs)
    ✓ Forced-error tests (FETs)
    ✓ Exploratory testing
    ✓ etc.
    Feature-Level Testing

    View full-size slide

  25. THE TOP-DOWN
    APPROACH

    View full-size slide

  26. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    ✓ each independent component is a
    different system
    ✓ kickstart makes a big difference
    Think System Level

    View full-size slide

  27. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    ✓ Where to start in the process
    ✓ What to test and what not to test
    ✓ How much to test in one go
    ✓ What to call the tests
    ✓ How to understand why a test fails
    Behaviour-Driven Development

    View full-size slide

  28. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    BDD Example

    View full-size slide

  29. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    BDD Example

    View full-size slide

  30. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    ✓ varies greatly, depending on project
    ▸ your product
    ▸ reseller
    ▸ outsource
    ✓ using BDD significantly lowers TCO
    Total Cost of Ownership

    View full-size slide

  31. Test automation is
    software
    development.
    Dale H. Emery3

    View full-size slide

  32. GETTING THINGS
    DONE

    View full-size slide

  33. Start teaching
    your developers
    testing today.
    Practice #1

    View full-size slide

  34. Rotate your
    developers to
    do testing.
    Practice #2

    View full-size slide

  35. Adopt
    systematic
    testing methods.
    Practice #3

    View full-size slide

  36. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    Systematic Testing Methods
    component
    KPRWVU
    QWVRWVU
    UKFGGHHGEVU

    View full-size slide

  37. Fixture-based
    development.
    Practice #4

    View full-size slide

  38. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    Fixtures

    View full-size slide

  39. Automate scenario
    runs to address
    regression.
    Practice #5

    View full-size slide

  40. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    1. Conway, Melvin E. (1968). How Do Committees Invent?
    2. Cook, Richard I. (1998). How Complex Systems Fail
    3. Emery, Dale H. (2009). Writing Maintainable Automated
    Acceptance Tests
    4. Nguyen, Hung Q., Bob Johnson, and Michael Hackett
    (2003). Testing Applications on the Web: Test Planning for
    Mobile and Internet-Based Systems. Wiley Publishing Inc.
    ISBN: 0-471-20100-6
    5. North, Dan (2006). Introducing BDD
    Recommended Reading (1)

    View full-size slide

  41. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day, MAY 2016
    6. Fowler, Martin (2009). Technical Debt Quadrant
    7. Gleick, James (1996). A Bug and A Crash
    8. Martin, Robert Cecil (2009). A Mess is not a Technical Debt
    9. Securities and Exchange Commission (2013).
    Administrative Proceeding File No. 3-15570
    10. Seven, Doug (2014). Knightmare, A DevOps Cautionary Tale
    11. PA Consulting Group (2011). Major UK water utility -
    Architecture and design assurance
    Recommended Reading (2)

    View full-size slide

  42. THANK YOU
    Georgiana Gligor
    @gbtekkie

    View full-size slide