Presenting Abstract Feature Branch at Montreal.rb April 2015

I am giving a talk at this month's Montreal.rb user group, taking place next week on April 21, 2015:
http://www.montrealrb.com/2015/04/april-21th-meetup/

Abstract:

How many times do you find yourself near the software release finish line on an exciting new feature only to be pulled off by management in the last minute to sneak in some higher priority emergency fix? What do you do with the unfinished feature's code if parts of it were already functional and merged into master? Do you pluck it out and move to a remote feature branch? Do you simply comment out the code not ready for exposure to the customer? What about some of the nice software design improvements that were done as part of the feature and are being put to good use by the team today? Do you also put design improvements off till the feature is deemed by management high priority again?

These questions typically get decided on by the team on a case by case basis, and often with big compromises affecting both project delivery and code quality.

While consulting for Sears in 2009 and working at Groupon.com in 2012, I happened to work in teams that adopted a very effective and inexpensive solution to the problem called "Branch by Abstraction", a technique originally popularized by Martin Fowler, author of UML Distilled and Patterns of Enterprise Application Architecture.

In this talk, I aim to explain Branch by Abstraction and demonstrate how to apply in Ruby using a gem I wrote called Abstract Feature Branch, partly inspired by the internal team libraries used at Sears and Groupon. The gem has already had over 50,000 downloads from rubygem.org and has been utilized in several of my newer projects, including launch of EarlyShares.com and enhancements of Factor75.com.

Attendees should walk out with basic understanding of Branch by Abstraction and enough knowledge of Abstract Feature Branch to be able to explore further in their own projects after the talk.