Pycon 2015 - Technical Debt - The Monster in Your Closet

  • Published on
    14-Jul-2015

  • View
    51.048

  • Download
    2

Embed Size (px)

Transcript

<ul><li><p>TECHNICAL DEBT !</p><p>THE CODE MONSTER IN YOUR CLOSET</p><p>Nina Zakharenko@nnja</p></li><li><p>WHAT IS TECHNICAL </p><p>DEBT?</p></li><li><p>(BOTH BUSINESS &amp; TECHNICAL)</p><p>A SERIES OF BAD DECISIONS</p></li><li><p>WHICH LEAD TOERROR PRONE CODE </p><p>&amp; ARCHITECTURE</p></li><li><p> AND USING MORE</p><p>TO ACCOMPLISHRESOURCES</p><p>LESS</p></li><li><p>What decisions were made in the past</p></li><li><p>that prevent me from getting sh** done today?</p></li><li><p>WHAT CAUSES IT?</p></li><li><p>ME.AND YOU.</p></li><li><p>Mistakes I Made Early On</p><p>Not knowing how to say NO to features</p><p>Not seeing the value in Unit Tests</p></li><li><p>Mistakes I Made Early On</p><p>Overly Optimistic Estimates</p><p>Putting releases over good design &amp; reusable code</p></li><li><p>TIME CRUNCH</p><p>The project was due yesterday!</p><p>Ill take a shortcut, and clean up the mess tomorrow.</p></li><li><p>UNNEEDED COMPLEXITY</p><p>Lines of code committed != amount of work accomplished.</p></li><li><p>Step 1: Have a problem.</p><p>Step 2: Look up How to do it on Stack Exchange</p><p>LACK OF UNDERSTANDING</p><p>Step 3: Copy and Paste it into your codebase</p><p>Step 4: ???</p><p>Step 5: Bugs!</p></li><li><p>CULTURE OF DESPAIR</p><p>This is already a heap of trash.</p><p>Will anyone really notice if I add something to the top?</p></li><li><p>RED FLAGSHouston, We Have a Problem.</p></li><li><p>CODE SMELLS?</p><p>Not bugs.</p><p>An indication of a deeper problem.</p></li><li><p>CODE SMELLS</p><p> Half implemented features No or poor documentation</p></li><li><p>CODE SMELLS</p><p> Commented out code, incorrect comments No tests or broken tests</p></li><li><p>POOR DOCUMENTATIONclass OrganicGlutenFreePizzaFactory: def get_dough(self): """ Return amazing, organic, GMO and Gluten Free Dough """ # ran out of organic gluten free, use the other stuff. !</p><p> # return 'organic gluten free dough' return 'gmo white pesticide dough' </p></li><li><p>ARCHITECTURE &amp; DESIGN SMELLS</p><p> Parts of the code that no one wants to touch Changing code in one area breaks other parts of the </p><p>system Severe outages caused by frequent &amp; unexpected </p><p>bugs</p></li><li><p>GOOD DESIGNImplementing new features comes easily.</p><p>BAD DESIGNShoe-horning new features into the system.</p></li><li><p>PYTHON SPECIFIC SMELLS</p></li><li><p>Functionality Changes, Variable names Dont.</p><p>employees = ['John', 'Mary', 'Dale'] !</p><p>employees = 'Bob' !</p><p>employees[0]</p></li><li><p>Monkey Patching</p><p>def new_init(self): pass !</p><p>some_library.SomeClass.__init__ = new_init </p></li><li><p>What exactly does that decorator do?def decorator_evil(target): return False !@decorator_evil def target(a,b): return a + b !&gt;&gt;&gt; target False !&gt;&gt;&gt; target(1,2) TypeError: 'bool' object is not callable </p></li><li><p>Circular Dependencies</p><p>def some_function(x): from some.module import some_method some_method(x) </p></li><li><p>CASE STUDIES</p></li><li><p>IRS CHIEF:</p><p>"We Still Have Applications That Were Running When JFK Was President"</p></li><li><p>50 Year old Technology</p><p>"And we continue to use the COBOL programming language, it is extremely difficult to find IT experts who </p><p>are versed in this language.</p></li><li><p>Its not just the IRS.</p><p>Banks &amp; Financial Insitutions Universities </p><p>Air Traffic Control !</p><p> all use COBOL. </p></li><li><p>STORY TIME</p><p>I used to work in finance.</p><p>At the time I was there, all of the banking systems were run on mainframes. </p><p>The bankers were getting frustrated. They wanted a UI.</p></li><li><p>IDEA!</p><p>Lets write a fancy new web front end.</p><p>Itll do ALL the things.</p></li><li><p>BUT</p><p>Rewriting the backend is too expensive. !</p><p>It already does what we need. !</p><p>Lets leave the mainframe.</p></li><li><p>CURSORS</p><p>The mainframe would output a text screen from a program result, based on a query.</p><p>The results would be parsed by reading variables from the screen in certain positions.</p></li><li><p>RESULT?</p><p>The new system was incredibly slow.</p><p>And error prone.!</p><p>After months of work, the multi-million dollar rewrite was scrapped.</p></li><li><p>YOU CAN PUT LIPSTICK ON A PIG</p></li><li><p>THE MVP</p><p>(Minimum Viable Product)</p><p>Get the product to early customers as soon as possible.</p></li><li><p>A GREAT IDEA</p><p>I worked on a project that was created by a lone developer in a coffee fueled 48 hours.</p><p>It was a great success.</p></li><li><p>THERE WAS A PROBLEMYears went on, but the initial code and design didnt go </p><p>away.Instead, it became the base for an expanding project, </p><p>with expanding features.</p><p>Worse, there was never any time to refactor.</p></li><li><p>SCOPE CREEP</p><p>Features that someone thought was a good idea one day, stuck around forever.</p><p>In case we need them. Later.</p></li><li><p>SAD DEVELOPERS</p><p>That made it feel like your fault.</p><p>When a release was pushed, something was bound to break.</p><p>There were no working tests.</p></li><li><p>GRINDING TO A HALT</p><p>Development time for new features skyrocketed.</p><p>The project was deemed too difficult to maintain.</p><p> and cancelled.</p></li><li><p>SOMETIMES YOU NEED TO BURN IT. WITH FIRE.</p></li><li><p>BATTLING THE MONSTER</p></li><li><p>Technical Debt is a team-wide problem.</p><p>Everybody needs to be a part of the solution.</p><p>DONT POINT FINGERS</p></li><li><p>WORK TOGETHER</p><p>Code Standards</p><p>Pair Programming</p><p>Code Reviews</p></li><li><p>Unless something is on fire, or youre losing money, unreviewed code should never be merged into master.</p></li><li><p>STAY ACCOUNTABLEUnit &amp; Integration Tests</p><p>Pre-Commit Hooks</p><p>Continuous Integration</p></li><li><p>SELL IT TO MANAGEMENT</p><p>By allocating some project time to tackling debt, the end result will be less error prone, easier to maintain, </p><p>and easier to add features to.</p></li><li><p>TIME</p><p>COST</p><p>Source: https://msdn.microsoft.com/en-us/magazine/ee819135.aspx</p><p>NOT BROKEN, WHY FIX IT?</p></li><li><p>SKI RENTAL PROBLEM</p><p>Youre going skiing for an unknown number of days. !</p><p>It costs $1 a day to rent, or $10 to buy.</p><p>Source: http://en.wikipedia.org/wiki/Ski_rental_problem</p></li><li><p>Technical debt frustrates developers.</p><p>Frustrated developers are more likely to leave.</p><p>THERES ANOTHER COST</p><p>Hiring developers is hard.</p></li><li><p>Figure out the project tolerance and work with it.</p><p>Dont be a perfectionist.</p><p>Some lingering technical debt is inevitable.</p></li><li><p>Use these arguments to justify the additional time it takes you to do things right.</p></li><li><p>Always code as if the guy who ends up maintaining your code will be a violent </p><p>psychopath who knows where you live.</p><p>- Martin Golding@</p></li><li><p>TO WIN THE FIGHT</p><p>PAY DOWN YOUR DEBT</p></li><li><p>PRIORITIZE</p><p>What causes the biggest &amp; most frequent pain points for developers?</p></li><li><p>What is the life expectancy of this project?</p><p>longer shelf life &gt; higher interest</p><p>SHELF LIFE</p></li><li><p>Just like with monetary debt, pay off the high interest loan first.</p></li><li><p>If you dont have to pay it off, you got something for nothing.</p><p>Technical Debt can be strategic.</p></li><li><p>Is the single greatest tool in your toolbox.</p><p>REFACTORING</p></li><li><p>Systematically changing the code without changing functionality, while improving design and readability.</p><p>WHAT IS IT?</p></li><li><p>Slow and steady wins the race.</p><p>REFACTORING</p><p>The end goal is to refactor, without breaking existing functionality.</p></li><li><p>Replace functions and modules incrementally.</p><p>REFACTORING</p><p>Test as you go.</p><p>Tests are MANDATORY at this step.</p></li><li><p>How you make time for refactoring depends on the size of your team.</p><p>MAKING TIME</p><p>(And the size of your problem)</p></li><li><p>Devote a week every 6 - 8 weeks.SMALL</p><p>MEDIUMDevote a person per week, rotate.</p><p>LARGEEveryone devotes 10% of their time.</p></li><li><p>A FEW LAST TIPS</p></li><li><p>CODE IS FOR HUMANS</p><p>Source: http://despairsoftware.blogspot.com/2014/05/engineering-principles-software-best.html</p><p>Despite common misconception, code is not for computers. </p><p>!</p><p>Code is for humans to read.</p></li><li><p>DONT REPEAT YOURSELF</p><p>Source: http://despairsoftware.blogspot.com/2014/05/engineering-principles-software-best.html</p><p>If being DRY requires mind-bending backflips and abstractions, stop.</p><p>(BUT)</p></li><li><p>THE BOY SCOUT RULEThe Boy Scouts have a rule: "Always leave the </p><p>campground cleaner than you found it." </p><p>Source: http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule</p><p>"Always check a module in cleaner than when you checked it out." </p></li><li><p>EXPECT TO BE FRUSTRATEDThe process of cleaning up days / months / years </p><p>of bad code can be analogous with untangling a ball of yarn. </p><p>!</p><p>Dont give up.</p></li><li><p>THANK YOU!Im Nina Zakharenko</p><p>@nnja /nnja </p><p>nnja.dev@gmail.com!</p><p>"#</p></li></ul>