Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account? Log In

NOTES - Build for Disable Preso - NOTES by Mind Map: NOTES - Build for Disable Preso - NOTES
0.0 stars - reviews range from 0 to 5

NOTES - Build for Disable Preso - NOTES

Build for Disable Techniques

Simple if check with a static boolean

Add a method for the alternate way and static boolean

Extend the class and override the methods you want to change. Point the app config at the new class, and to disable point to old class

Actually USE interfaces!!

Leads to better coding practices in general

The Goals

I want you to be productive... every day

I want you to give you options on how to stop fearing merging and how to start improving your product confidently

I want you to stop thinking of your code as a version and start thinking of your code as a living entity

Presenter Info

Nicholas Tuck

This preso url:

twitter: @nicholastuck

Find me on G+ (not kidding) seriously...

Preso Title: Your Code is Not a Version: How 'Build for Disable' can bring you true continuous integration

The Room for Improvement (room picture?)

Commit graph with feature branches (1a)

Commit graph with highlight of duplicate work (1c)

Commit graph with a release and all the features that didn't make it (1c)

Simple Solution

Commit hourly and push daily

Why Isn't Everyone Doing This? Introducing 'Build for Disable'

The reason why you don't see more teams doing true continuous integration is because we believe our code exists in versions

I have a solution

In closing

Your code as a version

Your code alive (on mountain dew)

Review goals and identify where they are represented on the graphs


Does this only work if there exists a good automated test suite on the project?

When do we remove the extra and disable code?

When do we peer review the code? Before disable code is removed or after?