Video: https://www.youtube.com/watch?v=JKYktDRoRxw
Pycon 2015 Montreal
Nina Zakharenko
Technical Debt - The Code Monster in Your Closet
Description
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.
Abstract
I've worked at many institutions with many programming languages over the past 8 years They all have technical debt. Putting on a band-aid and ignoring the real issues can be disastrous. We'll go through several case studies, review big red flags, and learn how to start chipping away at the problem with confidence.
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?
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
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
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.
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.
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.
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.
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
@
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.