Going Evergreen, RubyConf 2014

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

Unchanged teams rebuild

legacy problems


It will take 3-10 times longer

than expected

because … waterfall


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”

http://blog.codeclimate.com/blog/2013/12/19/are-you-experiencing-technical-drift/

Adjusted

Initial Velocity

Realistic Goals

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


Treating maintenance

the same as launch

will lead to

diminishing velocity

because … technical debt


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

Open/Closed

• Open for extension

• Closed for modification

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

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

Problem Solved?

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”

Team

Code

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

Faith?????

Kane Baccigalupi

@rubyghetto

Going Evergreen

Going Evergreen, RubyConf 2014

Technology

Transcript of Going Evergreen, RubyConf 2014