Unretrofittable: Starting off right

Some abstractions are hard to (un|re)do...

Chris Winters (@cwinters) - ModCloth

Pittsburgh Techfest 2014


Things start out great

Greenfield projects are the best, right?

It all made sense at the time

Does it matter why?

"agile" vs AGILE

What is your job?

Help others be awesome

...what we do is a means, not an end

Change as change does


Frying pan?

Empathy with doing, empathy with tasks

Also: side effects

Lever 1: Creating a usable system

One command to create a system with real(-ish) data.

Hard part: real(-ish)

"But I have fixtures!"

Can your domain experts edit them?

Abstractions shape ideas

So many forms

Thinking in tasks

Tasks will cause you pain

Fowler: "If it hurts, do it more often."

Side effects, you

Quick startup for new hires or changing teams. Which means people can change teams more often!

Head off model drift and too-generic data models

Side effects, others

Domain experts define and maintain data

Sales + marketing can create and customize demos

Potential users can create demos with their own data (woo cloud!)

Lever 2: Audit

Why do you even?

Cooler than it sounds

More abstractions

Refactoring resistant

Record tasks, not results

What could we do with that record?

Other side effects

Confidence in the system: things can be explained!

Exposing intent -- RecoverPassword vs ResetPassword and SendPasswordRecoveryEmail

Lever 3: Undo

Again with the tasks

Grace period

Wait a while to do your work, don't do it if asked

No free lunch

Change as Commands

Represent change as commands, represent undone change as commands

Side effects

Users can experiment! Less fear! So much happiness!

Lever n: Feature flags

Compile/build setting controlling feature accessibility


Thinking differently about features

Full functionality vs not breaking

Not the prettiest...

I'll just code that up...

You don't have to! (Flip, Setler, Togglz)

But I want clean!

Side effects++

Release more often; A/B testing

Related: Kill switch

You might also know me...

Runtime flag removing functionality due to disruption, planned or not

Wouldn't read-only be nice?

Why? Enabling schema change for broken databases

Side effects

<discuss>What actually happens when things fail?</discuss>

Others to think about

  • Start production sequences at 1000 so have an easy 'this is special' hook (id < 1000). (REI Outlet items, Larry Wall Huffman coding)
  • Avoid 'magic' values your platform might have (woe be the user with ID 4 in a ruby system...)
  • Extract metrics via API: generic performance as well as performance specific for your app (Carol's example from devopsdays)
  • Classify and contextualize errors - enable that intent you've exposed via your user actions to people troubleshooting later on. (YOU NEVER DO THIS LATER)

Others to think about

  • Validation
  • Act-as-user for internal admins and customer support
  • Authen/Authz
  • Schema updates
  • Caching hooks everywhere

Others to think about

  • Version internal dependencies to enable change (weight documentation example)
  • URI creation
  • Serialization and marshalling
  • Timezones!
  • "It's easier to make a stream system batch than make a batch system stream." (@dehora)

Thank you!

@cwinters - goo.gl/J4Tcoq