1 of 33

Tinkertoys, Microservices, and Feature Management

How to build for the future

2 of 33

SpaceRails

@wiredferret

3 of 33

Could be worse

@wiredferret

4 of 33

The state of the now

@wiredferret

5 of 33

The future is fractal

@wiredferret

6 of 33

Why do we test?

@wiredferret

7 of 33

What do we test for?

@wiredferret

8 of 33

9s don’t matter if the user is unhappy.

@mipsytipsy

@wiredferret

9 of 33

The trouble is toil

Manual
Repetitive
Automatable
Tactical
No enduring value
Scales badly

@wiredferret

10 of 33

Useful tests

End-to-end message time
Availability
Request performance
Accurate responses
Usability
Accessibility

@wiredferret

11 of 33

Facade tests

Code coverage
Only the happy path
Only clean data
Staging

@wiredferret

12 of 33

The beautiful future

@wiredferret

13 of 33

Self-healing

@wiredferret

14 of 33

@wiredferret

15 of 33

Modular

(microservices)

@wiredferret

16 of 33

A distinctive method of developing software systems that tries to focus on building single-function modules with well-defined interfaces and operations.

— SmartBear

@wiredferret

17 of 33

Semantics > Syntax

@wiredferret

In the beautiful future, a lot of our work has been taken by robots or automation. They’re not smarter than we are, but they never accidentally add an extra space in Python. As we climb up layers of abstraction from machine language, we are getting closer to telling programs what to do, instead of how to do it. After all, we can only tell computers how to be slightly dumber (if more patient) than we are.

This is the airbag construction from the Pathfinder mission. Remember my friend who helped me with the marble game? He helped build this rover, too. We didn’t have to teach anything how to bounce. Bouncing is physics. Physics engines are now so trivial to write that we use them to distress adults with the game about the goat that licks things. We set some parameters and let our computer/robot friends figure it out.

—-

Computers can teach themselves how to be smart and “creative” if we let them work things out in a structured way. The Go-playing computer teaching itself novel moves is a great example. We didn’t say “This is how to play Go, these are all the known human moves” We said “Here are the rules of Go. Knock yourself out.”

18 of 33

Testing experience, not embodiment

@wiredferret

19 of 33

How’s your thyroid feel?

@wiredferret

20 of 33

Why microservices are like Tinkertoys

@wiredferret

21 of 33

By honeyflorida (ebay item 120137669430, GNU FDL granted by owner.)

@wiredferret

22 of 33

@wiredferret

23 of 33

Yours, Mine, and Ours

@wiredferret

24 of 33

Combinatoric Testing Complexity

@wiredferret

25 of 33

@wiredferret

26 of 33

All On

All Off

Status Quo

Status Quo +/- Flag

@wiredferret

27 of 33

Do all the things in production

@wiredferret

28 of 33

This is a roadmap

It may not be your roadmap

@wiredferret

29 of 33

Start with small victories

Estimate what’s possible

Eat the whale

@wiredferret

30 of 33

When it goes well

@wiredferret

31 of 33

When it’s bumpy

@wiredferret

32 of 33

tl;rt

Monoliths are the past
Full test coverage is not a thing anymore
What is more important than how
Test in production

@wiredferret

33 of 33

launchdarkly.com/heidi

@wiredferret