Nina Zakharenko - Technical Debt - The code monster in everyone's closet

Nina Zakharenko - Technical Debt - The code monster in everyone's closet

Technical debt is the code monster hiding in everyone's closet. If you ignore it, it will terrorize you at night. To banish it and re-gain your productivity, you'll need to face it head on.

https://us.pycon.org/2015/schedule/presentation/424/

D5710b3bca38f1233274b4cbc523dc4b?s=128

PyCon 2015

April 18, 2015
Tweet

Transcript

  1. TECHNICAL DEBT ! THE CODE MONSTER IN YOUR CLOSET Nina

    Zakharenko @nnja
  2. WHAT IS TECHNICAL DEBT?

  3. (BOTH BUSINESS & TECHNICAL) A SERIES OF BAD DECISIONS

  4. WHICH LEAD TO ERROR PRONE CODE & ARCHITECTURE

  5. … AND USING MORE TO ACCOMPLISH RESOURCES LESS

  6. What decisions were made in the past

  7. that prevent me from getting sh** done today?

  8. WHAT CAUSES IT?

  9. ME. AND YOU.

  10. Mistakes I Made Early On Not knowing how to say

    NO to features Not seeing the value in Unit Tests
  11. Mistakes I Made Early On Overly Optimistic Estimates Putting releases

    over good design & reusable code
  12. TIME CRUNCH The project was due yesterday! I’ll take a

    shortcut, and clean up the mess tomorrow.
  13. UNNEEDED COMPLEXITY Lines of code committed != amount of work

    accomplished.
  14. Step 1: Have a problem. Step 2: Look up How

    to do it on Stack Exchange LACK OF UNDERSTANDING Step 3: Copy and Paste it into your codebase Step 4: ??? Step 5: Bugs!
  15. CULTURE OF DESPAIR This is already a heap of trash.

    Will anyone really notice if I add something to the top?
  16. RED FLAGS Houston, We Have a Problem.

  17. CODE SMELLS? Not bugs. An indication of a deeper problem.

  18. CODE SMELLS • Half implemented features • No or poor

    documentation
  19. CODE SMELLS • Commented out code, incorrect comments • No

    tests or broken tests
  20. POOR DOCUMENTATION class OrganicGlutenFreePizzaFactory: def get_dough(self): """ Return amazing, organic,

    GMO and Gluten Free Dough """ # ran out of organic gluten free, use the other stuff. ! # return 'organic gluten free dough' return 'gmo white pesticide dough'
  21. ARCHITECTURE & DESIGN… SMELLS • Parts of the code that

    no one wants to touch • Changing code in one area breaks other parts of the system • Severe outages caused by frequent & unexpected bugs
  22. GOOD DESIGN Implementing new features comes easily. BAD DESIGN Shoe-horning

    new features into the system.
  23. PYTHON SPECIFIC SMELLS

  24. Functionality Changes, Variable names Don’t. employees = ['John', 'Mary', 'Dale']

    ! employees = 'Bob' ! employees[0]
  25. Monkey Patching def new_init(self): pass ! some_library.SomeClass.__init__ = new_init

  26. What exactly does that decorator do? def decorator_evil(target): return False

    ! @decorator_evil def target(a,b): return a + b ! >>> target False ! >>> target(1,2) TypeError: 'bool' object is not callable
  27. Circular Dependencies def some_function(x): from some.module import some_method some_method(x)

  28. CASE STUDIES

  29. IRS CHIEF: "We Still Have Applications That Were Running When

    JFK Was President"
  30. 50 Year old Technology "And we continue to use the

    COBOL programming language, it is extremely difficult to find IT experts who are versed in this language.”
  31. It’s not just the IRS. Banks & Financial Insitutions Universities

    Air Traffic Control ! … all use COBOL.
  32. STORY TIME I used to work in finance. At the

    time I was there, all of the banking systems were run on mainframes. The bankers were getting frustrated. They wanted a UI.
  33. IDEA! Let’s write a fancy new web front end. It’ll

    do ALL the things.
  34. BUT Rewriting the backend is too expensive. ! It already

    does what we need. ! Let’s leave the mainframe.
  35. CURSORS The mainframe would output a text screen from a

    program result, based on a query. The results would be parsed by reading variables from the screen in certain positions.
  36. RESULT? The new system was incredibly slow. And error prone.

    ! After months of work, the multi-million dollar rewrite was scrapped.
  37. YOU CAN PUT LIPSTICK ON A PIG

  38. THE MVP (Minimum Viable Product) Get the product to early

    customers as soon as possible.
  39. A GREAT IDEA I worked on a project that was

    created by a lone developer in a coffee fueled 48 hours. It was a great success.
  40. THERE WAS A PROBLEM Years went on, but the initial

    code and design didn’t go away. Instead, it became the base for an expanding project, with expanding features. Worse, there was never any time to refactor.
  41. SCOPE CREEP Features that someone thought was a good idea

    one day, stuck around forever. “In case we need them. Later.”
  42. SAD DEVELOPERS That made it feel like your fault. When

    a release was pushed, something was bound to break. There were no working tests.
  43. GRINDING TO A HALT Development time for new features skyrocketed.

    The project was deemed too difficult to maintain. … and cancelled.
  44. SOMETIMES YOU NEED TO BURN IT. WITH FIRE.

  45. BATTLING THE MONSTER

  46. Technical Debt is a team-wide problem. Everybody needs to be

    a part of the solution. DON’T POINT FINGERS
  47. WORK TOGETHER Code Standards Pair Programming Code Reviews

  48. Unless something is on fire, or you’re losing money, unreviewed

    code should never be merged into master.
  49. STAY ACCOUNTABLE Unit & Integration Tests Pre-Commit Hooks Continuous Integration

  50. SELL IT TO MANAGEMENT By allocating some project time to

    tackling debt, the end result will be less error prone, easier to maintain, and easier to add features to.
  51. TIME COST Source: https://msdn.microsoft.com/en-us/magazine/ee819135.aspx NOT BROKEN, WHY FIX IT?

  52. SKI RENTAL PROBLEM You’re going skiing for an unknown number

    of days. ! It costs $1 a day to rent, or $10 to buy. Source: http://en.wikipedia.org/wiki/Ski_rental_problem
  53. Technical debt frustrates developers. Frustrated developers are more likely to

    leave. THERE’S ANOTHER COST Hiring developers is hard.
  54. Figure out the project tolerance and work with it. Don’t

    be a perfectionist. Some lingering technical debt is inevitable.
  55. Use these arguments to justify the additional time it takes

    you to do things right.
  56. “Always code as if the guy who ends up maintaining

    your code will be a violent psychopath who knows where you live.” - Martin Golding @
  57. TO WIN THE FIGHT PAY DOWN YOUR DEBT

  58. PRIORITIZE What causes the biggest & most frequent pain points

    for developers?
  59. What is the life expectancy of this project? longer shelf

    life —> higher interest SHELF LIFE
  60. Just like with monetary debt, pay off the high interest

    loan first.
  61. If you don’t have to pay it off, you got

    something for nothing. Technical Debt can be strategic.
  62. Is the single greatest tool in your toolbox. REFACTORING

  63. Systematically changing the code without changing functionality, while improving design

    and readability. WHAT IS IT?
  64. Slow and steady wins the race. REFACTORING The end goal

    is to refactor, without breaking existing functionality.
  65. Replace functions and modules incrementally. REFACTORING Test as you go.

    Tests are MANDATORY at this step.
  66. How you make time for refactoring depends on the size

    of your team. MAKING TIME (And the size of your problem)
  67. Devote a week every 6 - 8 weeks. SMALL MEDIUM

    Devote a person per week, rotate. LARGE Everyone devotes 10% of their time.
  68. A FEW LAST TIPS

  69. CODE IS FOR HUMANS Source: http://despairsoftware.blogspot.com/2014/05/engineering-principles-software-best.html Despite common misconception, code

    is not for computers. ! Code is for humans to read.
  70. DON’T REPEAT YOURSELF Source: http://despairsoftware.blogspot.com/2014/05/engineering-principles-software-best.html If being DRY requires mind-bending

    backflips and abstractions, stop. (BUT)
  71. THE BOY SCOUT RULE The Boy Scouts have a rule:

    "Always leave the campground cleaner than you found it." Source: http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule "Always check a module in cleaner than when you checked it out."
  72. EXPECT TO BE FRUSTRATED The process of cleaning up days

    / months / years of bad code can be analogous with untangling a ball of yarn. ! Don’t give up.
  73. THANK YOU! I’m Nina Zakharenko @nnja /nnja nnja.dev@gmail.com