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.

84cfe0e14cd3fdf8d1b2ef8223d99619?s=128

Georgiana Gligor

May 20, 2016
Tweet

Transcript

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

    2016 image source GEORGIANA GLIGOR
 TEKKIE CONSULTING
  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
  3. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day,

    MAY 2016 via Twitter
  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
  5. TECHNICAL DEBT

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

    Ward Cunningham
  7. A mess is not technical debt. Uncle Bob

  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?”
  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
  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
  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
  12. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day,

    MAY 2016 Team Distribution developers UX / UI testers managers DevOps
  13. THE BOTTOM-UP APPROACH

  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
  15. “REAL PROGRAMMERS DON’T TEST”

  16. My code works. I have a great track record. Why

    start now? Reason #1
  17. I am just making a small cosmetic change, nothing can

    go wrong. Reason #2
  18. Our client requested this functionality live by next Monday. We

    are short of time. Reason #3
  19. Client only pays for working software. Programmers are expensive, we

    can’t possibly sell this work. Reason #4
  20. We’re using V-Model approach. We’re not stepping on the dedicated

    QA team’s toes. Reason #5
  21. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day,

    MAY 2016 V-Model source: PA Consulting Group case study
  22. TESTING CONCEPTS

  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
  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
  25. THE TOP-DOWN APPROACH

  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
  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
  28. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day,

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

    MAY 2016 BDD Example
  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
  31. Test automation is software development. Dale H. Emery3

  32. GETTING THINGS DONE

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

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

  35. Adopt systematic testing methods. Practice #3

  36. Paying Technical Debt: A Top-Down Approach @ Shopware Community Day,

    MAY 2016 Systematic Testing Methods component KPRWVU QWVRWVU UKFGGHHGEVU
  37. Fixture-based development. Practice #4

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

    MAY 2016 Fixtures
  39. Automate scenario runs to address regression. Practice #5

  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)
  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)
  42. THANK YOU Georgiana Gligor @gbtekkie