Development Manual: Fast and Good

PRIORITIES

Priorities

1.Accuracy

2.Timeliness

3.Performance

Predictability >> Speed

Professionalism >> Heroism

Defense systems <=> New features &

integrations

Ethical Conduct, Always

When in doubt, ask!

THE VISION

How do we build software in a predictable,

professional way?

We manage the risk of change

It’s more risky to NOT change code

Let’s make it impossible to break the app

PROCESS GUIDELINES

All bugs are ultimately process failuresOur systems should reject bad changes

and enforce quality automatically

Deliver incremental results

What’s the 10% solution you could ship today?

Have more meetings• Make decisions

• Hash things out

• Explain your plan

• Brainstorm

• Write pseudocode

• Make diagrams

• Sharpen understanding

I, Mike Subelsky, heartily endorse meetings

IIF they entail decision-making, brainstorming, mentoring, conflict, fun, excitement

Conduct Root Cause Analysis After Every

Outage“The Five Whys”

Team leaders send weekly change updates

to all@

Prioritize automatic tests and quality control

over new features/integrations

Place one person on QA / bugfixing duty

each weekNeed a cool object to pass around the office

PROJECT PLANNING GUIDELINES

Set smaller goals you can actually achieve

We need more milestones, hard deadlines, “forcing functions”

3 Layers of Planning & Goalsetting

• Goals

• Epics

• Stories

Goal

• Strategic objective that helps STAQ grow

• Increases revenue or reduces costs, or both

• Expressed as a single sentence, completely in business terms, associated with a deadline

• “Charge customers for use of custom connections by 12/01/2015”

Epics• Major, high-level initiative to help achieve a Goal

• Complex effort encompassing changes to multiple codebases

• Expressed in business terms, in terms of user capabilities, with a deadline

• “Users can view, create, update, and delete custom connections on their own by 11/15/2015”

• Constantly reprioritized as the project deadline approaches

Push back• AMs/TAMs should always push us to deliver our best,

advocating for customer

• We should push back when real constraints exist

• Helps everyone be more creative

• Helps clarify priorities

• 80% / incremental solutions often good enough

• Resist the urge to dive in and save the day

Refactoring & maintenance cycles

• Count on about a week of fixing and polishing major features post-release

• After an epic or major project finishes, we do this anyway; let’s plan for it

• Good time to handle chores, smaller feature tickets & bug fixes

CODING GUIDELINES

Make small changes

Observe the Single Responsibility

PrincipleMost other OOP principles derived from this one

- https://en.wikipedia.org/wiki/Single_responsibility_principle

“…every class should have responsibility over a single part of the functionality provided by the

software.”

- https://en.wikipedia.org/wiki/Single_responsibility_principle

Responsibility is “…a reason to change…a class or module should have one, and only one,

reason to change.”

Deploy in AM/mid-day

Prefer to deploy heavy/breaking changes on

weekendsAvoid Sunday morning when collections run

Evening deploys OK but more dangerous

You’ll get lazy / sleepy Make a rollback plan

Use the staging server

• https://staging.staq.com

• https://sites.google.com/a/staq.com/staqnowledged/home/infrastructure/staging-server

Fork the app

• Good for testing database changes

• Need someone to try & document this

• https://devcenter.heroku.com/articles/fork-app

• May need to fork multiple apps in concert

• Heroku addon attachment feature pretty cool

Use feature flags

Create parallel gems/engines/

extractors/tables

Design solid code open to future change

But also beware of YAGNI (You Ain’t Gonna Need It)

Make it easy to testThis is the main point of BDD; produces better designs

Lint Ruby and JS Code

• Rubocop

• ruby -c after every save

• Let’s make this a git pre-commit hook

• brew install jsl

Keep writing tests• Unit tests: 100% coverage

• Usually no need to test explicit string contents

• Integration test: all major subsystems

• Including failure modes

• Acceptance test: most features, important failure modes

• Smoke test: engines/gems integrated into apps

Tests must always pass on CI

Fixing the build should usually take precedence over other work

Keep Classes Small

• “One screenful or less”

• Not counting documentation

• Almost no private methods

• There’s always a better way, look for a hidden object

Write many, many classes

Use clean architectural patterns

• 12factor

• Dependency injection

• Hexagonal architecture

Clear code >> documentation >>

comments

Refactor constantlyThink like a gardener, not like a landscaper

Make the change easy, then make the easy

change

Write many, many gems/engines

Continue peer code review

You are only done when…• Documentation written (YARD tags + wiki)

• Unit tests written to 100% coverage

• Integration tests covering important subsystem interactions

• Acceptance tests covering important features and failure modes

• Code reviewed by a peer

MONITORING AND ALERTING

Develop a few high-level, actionable alerts in staqmonitor

Many cool possibilities

We are going to build an immune system

Rejects bad changes

Develop indications and warning indicators

QUESTIONS?