Technical Pollution
Insights from the Lorax
Who are we?
Presenter: Andrea then Joe
full-service agency: design, dev, strategy
open source tech: share info in new engaging ways
Who are you?
Presenter: Andrea
PMs
developers
stakeholders
Presenter: Joe
smog was coined in London, not LA
no easy alternative, so they would cope; peppered moth
legislation: to be against coal was to be against progress
Great Smog of '52
What were the symptoms? illness, transit problems from low visibility
What were the causes? "things that make smoke"
What policies can mitigate the issue? 1956 Clean Air Act:
use clean energy
increase height of chimneys
implement "smoke free zones"
4,000 people died
inspiration for modern environmental movement
divide: pollution is natural vs progress w/o pollution control isn't progress
change wasn't immediate
Overview
What is technical debt?
What causes technical pollution?
How do you deal with technical pollution?
relation to tech debt:
1. monetary vs environmental
2. approach the same way
What is technical debt?
original context: agile financial software
iterating over a prototype
communicate the idea to his boss
"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." (Ward Cunningham )
comparison: delay effort to meet an objective
shorten time to market (fail fast)
preserve startup capital (delay a feature)
This is good!
"The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt." (Ward Cunningham )
danger of debt: cash flow
feature LOE > launch date
bug LOE > SLA
This is bad :(
Source: Fowler, M. 2009. Technical debt quadrant, Blog post at: http://martinfowler.com/bliki/TechnicalDebtQuadrant.html .
what is "not-quite-right"?
ideal/Ward: always clean code
pragmatic/Fowler: does debt describe what we observe?
TR: cut corner/abstract class
BR: evolution/prototype
TL: worst kind!/antipatterns
BL: jr dev/cruft
tech debt = not-quite-right code
debt payments vs building features
Brook's law: adding manpower makes it worse
fact: debt must be repaid
contextualize tech debt with other effort
why is tech debt neglected? invisible and negative
why is it important? velocity
expose and manage tech debt
The monetary analogy communicates the wrong idea.
Single metric? No.
Easy to measure? No.
Constant and deterministic impact? No.
suggests you think of money and technology in similar ways
this is false
The pollution analogy communicates the right idea.
Multi metric? Yes.
Difficult to measure? Yes.
Variable and probabilistic impact? Yes.
Pollution is a contaminate that causes adverse change in a system.
Tech debt is code that causes adverse change in a system.
How we measure and communicate it is similar
Managing your code is more like a garden than your bank account.
London smog isn't eliminated by a loan or a default
What causes technical pollution?
Presenter: Andrea for this entire section
And, for your information, you Lorax, I'm figgering on biggering
and BIGGERING
and BIGGERING
and BIGGERING,
turning MORE Truffula Trees into Thneeds
which everyone, EVERYONE, EVERYONE needs!
The story of the Lorax-the onceler
Flashback to the grass was still green, the pond was still wet, and the clouds were still clean
Onceler comes and finds the Truffula trees and has never seen trees such as these
So he chops it down. Gazump the Lorax smallish mossy voice sharpish bossy
Onceler biggers--gluppity glup, smogulous smoke
Hacks the last tree the Lorax lifts himself up
What does this have to do with Technical Pollution?
Schedule Pressures
Business is business!
And business must grow,
Regardless of crummies in tummies, you know.
Business Pressure
making promises
blue thneeds
Code Practices
complexity
inexperienced developers who dont know design patterns
Incomplete Tests
testable code is good code
Incomplete Documentation
no styleguide
no example code
no documented best practices
"I repeat" cried the Lorax, "I speak for the trees"
the trees have no tongues
I speak for the code
How do you deal with technical pollution?
Culture
Being "green" requires everyone on board, especially leadership.
Presenter: Joe
Palantir: zero-emission, recycling, garden, bike
Communicating invisible negative value to stakeholders requires the backing of your company from the top down.
Cultivate an environment of good code.
Culture
BDD language communicate business requirements without the business pressure (e.g. Gherkin).
Presenter: Joe
BDD keeps it formal
Culture
PM's need to support their Lorax.
Presenter: Joe
Enable Lorax to influence business decisions
Toyota's Andon pullchord
Code Practices
Presenter: Andrea
design patterns
teaching developers
known repeatable code
Code Standards
Presenter: Andrea
not just whitespace
yoda conditionals
unused variables
example code
Plan to Refactor
Agile is prone to technical debt because of YAGNI.
Presenter: Joe
architecture and agile are oil and water (Kruchten)
If you start with a bicycle, you can't iterate to a race car. You need a rewrite.
tradeoff of BUFD vs pivoting
Plan to Refactor
"An excellent time to refactor code is right before you extend it." (Ward Cunningham )
Presenter: Joe
Build refactor time into your development cycle.
Consider adding refactor buffers into work estimates.
Test Driven Development (TDD)
Presenter: Andrea
BDD is specific to behavior
TDD is about code as a testable entity from the beginning
good code is testable code
IBM/Microsoft
increased 15-35% dev time
decrease defects by 40-90%
Continuous Integration
Prevent pollution at the source.
Presenter: Joe
analogy: coal scrubbers
configure IDE to throw errors
use Git hooks
use a CI system to send alerts when code fails quality metrics
Continuous Integration
Define quality and the tolerance level of pollution.
(See phpqatools.org and phpmetrics.org )
Presenter: Joe
phpcs: Code style violations
phpdcd: Dead code
phpcpd: Copy and paste
pdepend: Cyclomatic complexity (phpqatools)
Listen to PHPMD! single best
Use CodeClimate or Scruitinizer
Code Review
Presenter: Andrea
when a real person looks at the code
teaching opportunity
last gate for making sure everything makes sense
UNLESS someone like you cares a whole awful lot, nothing is going to get better. It's not.
Presenter: Andrea
someone needs to speak to the code
support your Lorax
Questions?
References
(In order of reference during presentation.)
Dr. Seuss. The Lorax . New York: Random House, 1971. Print.
Brown, Paul. "50 years after the great smog, a new killer arises ." The Guardian, 2002.
Cunningham, Ward. "The WyCash Portfolio Management System ." c2.com, March 1992. Web. June 2015.
Fowler, Martin. "Technical Debt Quadrant ." martinfowler.com, October 2009. Web. June 2015.
Martin, Robert C. Clean Code . Boston: Prentice Hall, 2008. Print.
Krutchten, P. "What colour is your backlog? ." pkruchten.wordpress.com, December 2013. Web. June 2015.
Nagappan, Nachiappan, et all. "Realizing quality improvement through test driven development ." Empirical Software Engineering Volume 13. Issue 3 (2008): pp 289-302. Print.
The PHP Quality Assurance Toolchain. http://phpqatools.org .
PhpMetrics. http://phpmetrics.org .
Recommended Reading
All the references!
Brooks, Fred. The Mythical Man-Month: Essays on Software Engineering . Boston: Addison-Wesley, 1975. Print.
Gamma, Erich, et all. Design Patterns: Elements of Reusable Object-Oriented Software . Reading, Mass: Addison-Wesley, 1995. Print.
Denne, Mark, and Jane Cleland-Huang. Software by Numbers: Low-Risk, High-Return Development . Boston: Prentice Hall, 2003. Print.
Johann, Sven and Eberhard Wolff. "Managing Technical Debt ." www.infoq.com, May 2013. Web. June 2015.
Laribee, David. "Using Agile Techniques to Pay Back Technical Debt ." msdn.microsoft.com, December 2009. Web. June 2015.
Fowler, Martin. "Design Stamina Hypothesis ." martinfowler.com, June 2007. Web. June 2015.
Cunningham, Ward. "First Law Of Programming ." c2.com, December 2014. Web. June 2015.
Cunningham, Ward. "Ward Explains Debt Metaphor ." c2.com, January 2011. Web. June 2015.
Recommended Reading Cont'd
P. Kruchten, R. Nord, and I. Ozkaya. "Technical Debt: From Metaphor to Theory and Practice ." IEEE Software, Vol. 29. Issue 6 (2012): pp. 18-21.
A. Martini, J. Bosch, and M. Chaudron. "Architecture Technical Debt: Understanding Causes and a Qualitative Model ." www.researchgate.net, September 2014. Web. June 2015.
Ramakrishnan, Srinath. "Managing Technical Debt ." www.scrumalliance.org, July 2013. Web. June 2015.
Fowler, Martin. "Goto Fail, Heartbleed, and Unit Testing Culture ." martinfowler.com, May 2014. Web. June 2015.