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/

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