Going
Evergreen
Kane BaccigalupiFixer, Coder, Teacher
Greenfield
Brownfield
Evergreen?
Evergreen
After 1-2 years,
It is easier to work on
than the very beginning
Evergreen
• Know more about domain
• Abstractions for common features
• Product re-imagination
relatively cheap
Why do fields
go brown?
Everything we believed
became wrong
Our instincts
are to start over
Our instincts …
are wrong
An unchanged team will
rebuild themselves into the
same legacy problems
Law of the Optimistic Rebuild
An unchanged team will
rebuild themselves into the
same legacy problems
Law of the Optimistic Rebuild
Unchanged teams rebuild
legacy problems
Law of the Optimistic Rebuild
It will take 3-10 times longer
than expected
because … waterfall
Law of the Optimistic Rebuild
Corollary:
Why does
greenfield feel so
good?
Where does
that velocity
come from?
Borrowingfrom Gems (and standard lib)
• Code
• Architecture
• Product & Domain Assumptions
Technical Drift
http://blog.codeclimate.com/blog/2013/12/19/are-you-experiencing-technical-drift/
“It’s a phenomenon that occurs when a
development team continuously fails to recognize
and adapt to change, causing the concepts in the
software’s domain and the concepts in code to start
to slowly ‘drift’ apart from one another”
Adjusted
Initial Velocity
the Brownfield
progression
total features =
area under graph
flat velocity
>
brownfield trajectory
The best practices for
maintaining software are
different from best practices to
launch a software project
Law of Software Stages
Maintaining software
is different from
launching it
Law of Software Stages
Treating maintenance
the same as launch
will lead to
diminishing velocity
because … technical debt
Law of Software Stages
Corollary:
Maintenance
What are the best practices?
SOLID
Jim Weirich
SOLID
• Each class has one
responsibility
• It should only change
for one reason
Single
Responsibility
SOLID
Single
Responsibility
SOLID
Single
Responsibility
SOLID
Open/Closed
• Open for extension
• Closed for modification
SOLID
Open/Closed
SOLID
Open/Closed
SOLID
Open/Closed
SOLID
Liskov substitution
Let q(x) be a property provable
about objects x of type T. Then q(y)
should be provable for objects y of
type S, where S is a subtype of T.
SOLID
Liskov substitution
SOLID
Liskov substitution
violation
SOLID
Liskov substitution
SOLID
Liskov substitution
SOLID
Interface Segregation
SOLID
Interface Segregation
Appendage interface
SOLIDDependency
Inversion
• High-level things should not
depend on low-level things
• Abstractions should not depend
on details
SOLIDDependency
Inversion
+
SOLID
Goals?
Help us respond to change
SOLID
• Not very specific
• Rules are tightly coupled
• Motivated by change?
SOLID
Great guidelines if you
already know
this stuff.
SOLID
Not good enough
for junior or mid-level
engineers
Your team should
have SOLID design
expertise
Law of SOLID Advice
If you need a
SOLID teacher,
you need willing learners
Law of SOLID Advice
Corollary:
You need more specific
actionable things for your
learners until they
get to SOLID expertise
Law of SOLID Advice
Corollary:
If you don’t have a team of all SOLID
practitioners, how do you get to
evergreen?
Actionable
for everyone
Actionable
for everyone
Actionable
for everyone
Hire Sandi
-or-
Use Sandi’s 5 Rules
The 5 Rules
•Classes100 lines or less
Methods 5 lines or less
Arguments of 4 or less, including
each hash key/value pairs
… and 2 rails specific things … look it up
After a year, we were
evergreen
• Knew more about domain
• Abstractions for common features
• Product re-imagination
relatively cheap
Sandi came for another
consulting gig with us …
and I realized we weren't
doing what Sandi Metz would
do :(
Law of STD2
A large group of junior engineers practicing STD2
with just a little SOLID expertise
Small
<= 5 line methods
<= 75 line classes
STD2
Test Drive It
Don’t just test
Test-drive
STD2
1. Dependency Inject
— also —
2. Law of Demeter
STD2
As we ran into weird
code we would create
more rules, especially
when working
with Rails
STD2
Teams Make Code
Rules Don’t Make Code
Conway’s Law (I didn’t invent this one)
“organizations which design systems
... are constrained to produce designs
which are copies of the
communication structures of these
organizations”
Code
isCommunication
How should we choose
our team?
Weird Affective Metrics
(that work)
• Communicative
• Enjoyable
• Motivated
Weird Affective Metrics
(that work)
• Self-Aware
• Imposter <=> Arrogance
• Learning style
• Impact control
But what about tech
skills?
++ design
++ faith
Kane Baccigalupi
@rubyghetto
Going Evergreen