Portland OregonLast week I was in Portland Oregon for RailsConf 2013.  Portland is a great city with beautiful views of mountains that us East Coasters dream of, unusually good weather (last week anyways), and a very entertaining soccer team.  But none of that is why I spent a week and some long flights going there.  Here are eight takeaways I had from RailsConf…

1. Real Time Rails takes a step forward

Brian Cardarella demo’d how Rails 4 makes it easier to write real time apps in Rails that were previously better done in something like nodejs.  Brian’s slides are here, but most of his talk was a demo so the slides don’t do it justice.  For a hint of how this is done in Rails 4 you could also check out this blog post from Tender Loving.  To see how you can do similar things now before Rails 4, try out this blog post by Liam Kaufman.

2. Hiring Volatiles and Stables – So Happy Together?

On Monday night, Michael Lopp gave the evening keynote.  My takeaway from his entertaining (if rambling) talk was about how to build a successful but still innovative company, you need to balance the conflicting desires of very innovative-but-difficult-to-manage developers (the Volatiles) and those very reliable-but-not-very-creative developers that drift to more established companies RailsConf Exhibit Hall(the Stables).  As AgilityFeat grows, I can start to see this tension coming into play.  While this was not a technical talk or specific to Rails, there were some very good nuggets for where I am at right now.

3. Snappy Apps take advantage of asynchronous workers

David Kapp from coshx labs gave a very good overview of how to use asynchronous workers in rails, and it reminded me to remind myself to use them more often.  He listed these candidates for aynch calls:

  • call external apis, especially slow ones
  • number crunching
  • document generation
  • image or video manipulation
  • sending email
  • payment processing
  • geolocation

David was using Resque in his example, but other frameworks would work well too.  He suggested starting with 2 or 3 worker threads initially and then monitoring the workload, make sure things are not being queued faster than they can be processed.

4. Split Testing in Rails

RailsConf sessions were packed!Bryan Woods talked about how to do split testing using Rails, and introduced an open source frame called Experimental that has come out of his teams’ work.  They built this framework after realizing that doing simple splitting techniques like odd/even user id’s was not working well for users.  For example, they realized they typically gave all the changes to even numbered users, and so those user saw lots of changes all the time, making them look bad as a company.  The odd numbered users always saw stability and never a change.

Experimental allows them to bucket users and put them in specific experiments easier to ensure a better experience for everyone.

5. WTF is the deal with PRY?

Conrad Irwin gave a great tour of PRY, which is an alternative to the ruby console tool IRB.  It allows you to do all sorts of cool things like “ls” commands to see the methods on a class, code documentation, and the very entertaining “wtf?” command that shows part of the trace resulting from the most recent command.  Very useful stuff for debugging.

6. Datomic and “newSQL”

If you are tired of noSQL vs SQL debates, then you can take comfort in a third option:  what Yoko Harada called “newSQL.”  Yoko showed how the diametric gem will give ActiveRecord-like model functionality in Ruby on top of a Datomic data store.  Datomic’s “fact based” database is supposed to be very good for large-read database needs and also has a sense of time built into it that makes it easy to roll back data and look at what it was previously.

7. BDD for iOS? Yes you can with RubyMotion!

2013-05-02_07-02-15_34Brian Sam-Bodden showed us how to use MacBacon to do behavior driven development of an iOS app using Ruby Motion.  BDD is not something you normally see on iOS apps, and while RubyMotion is not appropriate for all mobile development it can be a very useful way to bridge the gap to mobile development for Rails developers.  Especially if you don’t want to give up your RSpec ways.

8. Running with Rails coders

The best things at conferences usually happen outside the sessions.  RailsConf is no exception.  Going to the Portland Timbers soccer game was great, but perhaps even better was taking the initiative to go running with some Rails coders.  Darin Swanson kindly organized two runs during the week.  One was a riverside run in downtown Portland and the second was a mountain top trail run near the Portland Zoo.  I ran a little farther on those runs than I typically do, because I was inspired by the scenery as well as the example set by those marathon coders I was running with.  It as a very friendly group and a real highlight of the trip –thank you to everyone I met along the way at RailsConf!

How do you convince engineers that it’s okay to build quick experiments, and deploy code that you will probably throw away? How do you convince rigorous engineers that it’s actually more efficient to work in a lean startup style?

That is a topic that Sam McAfee from Change.org addressed during a panel at the LeanStartupConference last December in San Francisco.

A little bit about Change.org

Screen Shot 2013-01-04 at 3.31.27 PMChange.org is “the world’s petition platform”, and a very cool social activism site where you can start petitions about issues you care about. These aren’t just petitions about your neighbor’s annoying cats, many of these petitions are about real life changing events on a global scale.

For instance, right now there are petitions highlighted on change.org to fight corrective rape in South Africa, to end driving license corruption in India, to allow women to drive in Saudi Arabia, and many more issues. Many of these petitions actually effect the change they are asking for, and Change.org marks those as “won.”

Sam McAfee’s journey to Lean

Screen Shot 2013-01-04 at 3.48.50 PMSam is director of Web Engineering at Change.org, and I appreciate how generous he was with his time. Sam and I talked more about the issues that he discussed on the engineering panel at the Lean Startup Conference, and we started with talking about his journey to the world or agile and lean startups.

Sam got into software development at the tail end of the dot com boom. He was first exposed to agile around 2002 or 2003. At the time he was building a consulting company and stumbled on Kent Beck and Martin Fowler, and was inspired to incorporate their eXtreme Programming (XP) techniques into his consulting company.

The methods of XP are great, and things like Test Driven Development and Pair Programming are a great way to become more agile. But in Sam’s experience, it’s easy to get lost in the mechanics of those practices but still lose sight of your core goals. The practices by themselves don’t automatically make you “agile”, and it took Sam a while to really grasp that. So far Sam’s story is very similar to my own, and so this was really ringing true to me.

The lean movement got it’s start more in overall business process design and some higher level concepts, and Sam started reading Mary and Tom Poppendieck and getting more exposed to the lean movement. The intersection of agile and lean was originally presented to him as “agile for the project and lean for the enterprise”. So Sam read all he could, going all the way back to reading about Deming’s process improvement work in the post WWII era. Reading Deming really helped him solidify his understanding of the goals that agile has.

As you can imagine by now, Sam is really jazzed about the increasing overlap of the lean and agile worlds.

Combining Lean Startup and Agile Engineering at Change.org

Screen Shot 2013-01-04 at 3.31.52 PMPrior to joining Change.org, Sam had already read Eric Ries’ book on Lean Startups. The team at Change.org was already embracing the “Build Measure Learn” loop, but getting a little lost in the practices. They were also using scrum, but it was only marginally successful. Estimation was all over the place, and stories were not always finished. They were starting to deploy regularly manually, but it wasn’t automated yet. Ultimately they decided that Scrum was holding them back.

Sam reached out to Eric Ries, and asked him to get on the phone and chit chat about how Change.org was applying lean startup ideas. They decided to start separating the work at Change.org into two broad areas: 1) work on well known domains, and 2) more unknown areas where Minimum Viable Products (MVPs) would be helpful.

Coding to learn

How do you get rigorous agile TDD engineers to think like Lean Startupers? For Sam, it required convincing engineers that sometimes code has the sole purpose of learning a thing rather than doing a thing. Crossing this mental block means it’s okay to throw that code away and not be too strict about how you code it.

Here are a few challenges that Sam and Change.org ran into initially:

  • The team had code quality very high in mind, which is great for a known problem. But when building a new business, it gets in the way of testing ideas.
  • You might not keep experiments or A/B tests – there’s at least a 50% chance that you won’t keep the code.
  • Engineers were aghast at the waste of a lean startup process initially.
  • They were afraid that quick & dirty code would get integrated with the rest of the app and left there as technical debt.
  • The team initially struggled to modularize the experiments, and send user segments to the experiments
  • Business stakeholders had to understand that even successful tests still need to be re-engineered

It took patience and some architectural changes, but now the team is pretty accomplished at running frequent lean experiments before they invest a lot of time in new ideas for Change.org.

Most of the experiments are a couple days to a week in length. They are integrated into the scrum sprints but not in a real formal way, and the experiments are not bound by the time box of the sprint. Product Owners have to indicate if a user story is related to an experiment or a permanent change on the site.

From the customers’ perspective, the features on the site just gradually change for users. There are no “big bang” releases or big announcements.

On the tech side, Change.org runs a Rails stack. Their Continuous Integration (CI) system is custom designed for their needs. The team can spin up AWS server instances to run tests on production type environments.

Code deploys happen multiple times a day with small clusters of features in them. These deployments are not fully automated yet, but the team continues to iterate towards that.

Automated testing is important for an environment that changes this frequently, and so the team writes RSpec and Cucumber tests at various levels of the system. Tests have to run parallelized now because the test suite is pretty large.

Closing thoughts

Lean Startups help tie together business and engineering concerns. This is a key point to Sam, and one of the big benefits. It makes it easier to show that every decision you make is ultimately an economic decision. Will this change help us achieve some goal with our customers or not? No tool should be purchased or software developed until you have proven it’s benefit in advance with lean experiments.

Engineers understandably want to wait to delay all code deployments until everything is perfect. And while it may feel dirty to deploy code that you know is not perfect, and doesn’t have fully automated tests around it, you need to make a distinction between code that is intended to be permanent, and code that is a temporary experiment.

As Sam pointed out, even Kent Beck says it’s ok to write some code without TDD. The agile engineering practices are good, but you have to understand the intent.

The lesson I am drawing from Change.org is that if you can draw a clear line between experiments and permanent code, build an architecture that allows you to run experiments easily, and attend to the cultural concerns of engineers and the business, then you too can balance rigorous agile engineering with highly efficient and dynamic lean startup software development.

Kent McDonald leads some volunteers from American Express who are helping write user stories and do product flows for Wishlisting.org

Get your green now before it’s too late!  Green Cucumber tests, that is. This is the last day of the Agile Dev Lab at the Agile 2012 conference, where we are working on the website wishlisting.org for charities to use for very specific fundraising needs.  Our beta client is AHIP, and you can donate online to them here:  http://wishlisting.org/list/AHIP

AHIP helps distressed families keep their homes in repair so that they are still able to live in them.  Unfortunately there’s a lot of people these days who have that need, and they have a waiting list of clients just in their region.  I’m very proud that the Agile Dev Lab has raised over $1000 for AHIP this week, and you can still buy raffle tickets until 5pm today!

Donate your time or funds to the Wishlisting.org project and you can help distressed families repair their homes! Donate online at wishlisting.org/list/AHIP

There’s also a lot of other ways you can help our Wishlisting.org project.  Come by and help write Cucumber tests or Ruby code, write user stories and acceptance criteria, or help test what we’ve done so far.  If you don’t know how to do any of that, don’t worry, we are happy to show you how!  You’ll learn something, teach us something, or just help out a great cause.

Look for us by the big quilt of Agile conference t-shirts that we are raffling off to raise money for AHIP!

Words to know and live by for a lean Startup

Lean Startup, by Eric Ries

If you haven’t read this book yet, you really should. Sounds daunting? Don’t worry – our team can help you live these principles and deliver awesome products efficiently!

Here at Agility Feat we use Lean methods to keep our business responsive and effective. But what does it mean to be Lean? Listed below are some of the core concepts of being Lean that we follow, and how it has helped make us better developers.

A Minimum Viable Product (MVP)

As part of the first stages of development a Lean development team needs to create a minimum viable product. The goal of an MVP is to test whether your business idea can succeed before you invest too much time and resources. Before rushing into development it is important to understand what a minimum viable product is for your business, and what kind of budget and time constraints you are dealing with.

There are some important things to know about an MVP that others have pointed out. First, its not just a less complete version of your final product. The MVP needs to be the essence of your value added proposition. Second you should know when to release your MVP based on the level of functionality you want, but you cannot sacrifice good design. Having a poorly designed but functional product will just scare away potential customers. Finally the MVP is a first step it is not the final goal, and once you have released it you still need to go through a process of change and experimentation.

Continuous deployment

With an MVP already deployed there is still a lot of work to be done. Continuous deployment is about getting that work done in small chunks and continually updating the website. There are a few big benefits to continuous deployment over the traditional big release schedule.

1. It will be easier to find bugs and errors in the code, because a small release has less new code to be searched through.

2. Errors are less likely to propagate. This ties in with the first benefit. Since you are discovering errors earlier you are not building as much code around something that is broken.

3. A tough to solve problem can be resolved faster and there are better opportunities for discovering workarounds. If you are stuck on trying to implement a feature, than its impossible to hide the lack of that feature in a small release. This forces you to talk with your customer about what they need from this feature, and explain why its difficult to implement. This process will hopefully lead to a healthy resolution of the problem.

4. A customer can see the progress being made on the website. If they don’t like how something was implemented then they can go to you before more code is added and that will mean less reworking of the code.

This blog has great advice on how to implement continuous deployment in 5 easy steps.

Split Testing

This is the pretty simple idea that if there are competing ways of implementing a product, you should try out both, and watch closely. Testing and validation are an important part of the Lean philosophy, but not just testing to see if code works. Its testing to see if a software product works for your customers and for you. There is some great advice out there on how to do split testing.

While split testing can be a little more hassle to implement than just following a single development line, its important to incorporate the process. It forces you to test your ideas against reality. No one is right all the time. Split testing, and testing in general can hopefully lead you to catch any errors in your assumptions before you invest too much.

Pivot

Pivoting is a big part of the lean philosophy. As a business you need to sometimes be able to change directions. Things haven’t gone as planned, customers didn’t respond as you expected, a big problem with the business has popped up suddenly, or you have found yourself moving down a path towards a dead end. These and other problems may indicate that you need to pivot.

It is easy to say you should pivot, but carrying out the philosophy is much more difficult. Pivoting can mean that you might have to trash old work, previous assumptions, or cherished ideas. Its hard to admit when the data says you’ve done something wrong, but you’ll be much better off admitting it and figuring out a new way forward. Lean methods are built to help make pivoting easier. Shorter development cycles mean that mistakes are caught quicker. Split testing gives you a head start on figuring out how to pivot.

Need more info? Join us at the beach!

We’re pleased that this blog post has generated some interest on twitter from big names (such as @EricRies himself). If you are interested in learning more about AgilityFeat’s awesome team of “Costa Rican Code Commandos” and how we can help your startup, please contact Arin Sime at 1-434-996-5226 or Arin@AgilityFeat.com. You can also follow @ArinSime on twitter.

We are also in the early stages of planning a workshop around startup development in Costa Rica. Why not learn how to apply these principles with a nearshore team, all while hanging out on the beach? You can learn some of the early ideas here and help validate them by joining our email list about the workshop! More details to be announced soon.

June 4-5, 2012 Washington, DC

 

DETAILS/REGISTRATION

For information on other dates
blog.agilityfeat.com/atdd-kickstart/

AgilityFeat is proud to be partnering with Lithespeed on our ATDD Kickstart classes, and so we’re pleased to announce an upcoming course near Washington DC! This class is designed to take your team from zero to test automation using Cucumber in a hands-on activity filled two days.

In our public courses, your team will learn:

Day 1 (For business, testing and development)

  • Overview of Test Driven Development, ATDD, and BDD
  • Writing acceptance criteria in Gherkin
  • Automating website testing with Cucumber
  • Continuous Integration using Jenkins to make it all sing

Day 2 (More focused on the development and testing roles with lots of hands on exercises and practice)

  • Basics of the Ruby language
  • Implementing step definitions in Cucumber

We can also teach this as a private course on site at your company, and customize it to your specific needs. Other topics we have incorporated into private courses include JRuby, Rails, Selenium, and RESTful API testing.

Prerequisites

Dave working with developers in a course

Participants need to bring their own laptops. Virtual images will be distributed during the class to attendees so they can have a working environment quickly. These images will have open source copies of Cucumber and Ruby pre-installed on a Ubuntu Linux desktop. No experience with Ruby, Cucumber, or Linux is required prior to the course.

About the instructors

Dave Haeffner is an experienced automated tester, and formerly the Senior Quality Assurance Analyst at The Motley Fool; responsible for creating, implementing, and overseeing their automated web testing infrastructure. He was a speaker at Agile 2010, an organizer of the DC Selenium meetups, and is an active member in the Selenium and Ruby communities. Dave has worked with small startups and large government contractors to improve their quality practices.

Arin explaining ATDD

Arin Sime is an agile coach, developer, and the founder of AgilityFeat. He has worked with teams at small startups, large corporations, and government agencies. He has been a speaker at Agile 2009, Agile 2010, XP2011, as well as other regional conferences. He brings his diverse background of technical and management experience to bear when coaching teams through process and engineering challenges.

Arin and Dave both hold an M.S. in Management of I.T. from the University of Virginia’s McIntire School of Commerce.

To book a seat in the Washington DC class, please visit: Lithespeed’s ATDD Training Page

To book a private course or a customized course for your team, please contact Arin Sime at Arin@AgilityFeat.com or +1 434 996 5226.

Dave Haeffner and I are proud to announce a new workshop on Acceptance Test Driven Development using Cucumber and Ruby that we are offering in 2012.  The workshop will initially be taught as private courses to companies, so if you are interested in a quote, please contact me at Arin@AgilityFeat.com or 434.996.5226.

ATDD Kick-Start with Cucumber and Ruby

This two-day workshop will take participants through the entire life cycle of automating your acceptance tests using Cucumber and Ruby.  The workshop is designed for people who are new to test automation and new to the Ruby language.  This course serves as an excellent introduction to both concepts, and is suitable for testers and developers alike.  Each attendee will work in pairs on actual tests and code throughout the two days, so that learning is maximized through hands on practice.

Workshop Topics

  • Overview of Test Driven Development, ATDD, and BDD
  • Intro to Cucumber
  • Writing Gherkin Acceptance Criteria
  • Step Definition basics
  • Intro to Ruby
  • Writing your step definitions in Ruby
  • Using RSpec to test assumptions
  • Automating website testing
  • Using Rails to build our website
  • Testing things besides websites
  • Refactoring Cucumber tests
  • Continuous Integration basics
  • Review of TDD/BDD concepts
  • Overview of other BDD implementations

Prerequisites

Participants need to bring their own laptops.  VMWare virtual images will be distributed ahead of time to attendees so they can have a working environment quickly.  These images will have open source copies of Cucumber and Ruby pre-installed on a Ubuntu Linux desktop.  No experience with Ruby, Cucumber, or Linux is required prior to the course.

About your instructors

Arin Sime is an agile coach, developer, and the founder of AgilityFeat.  Based in Virginia, he has worked with teams at small startups, large corporations, and government agencies.  He has been a speaker at Agile 2009, Agile 2010, XP2011, as well as other regional conferences.  He brings his diverse background of technical and management experience to bear when coaching teams through process and engineering challenges.

Dave Haeffner is the founder of Arrgyle — a company focused on helping people realize and achieve their potential through effective technology use. Before starting Arrgyle he was the Senior Quality Assurance Analyst at The Motley Fool; responsible for creating, implementing, and overseeing their automated web testing infrastructure. He was a speaker at Agile 2010 and is an active member in the Selenium and Ruby communities.

Arin and Dave both hold an M.S. in Management of I.T. from the University of Virginia’s McIntire School of Commerce.

 

Developing software for the cloud can make test-driven development more complicated, but not impossible. In this article that I wrote for TechWell.com and StickyMinds.com, I offer advice for continuing good development practices in the face of challenges from cloud hosting and distributed computing.

To see the article, visit either site:

TechWell.com

or

StickyMinds.com

Why are some developers so afraid of commitment? I’m not talking about relationships, but something equally as important. Committing your code to a repository before it goes stale or you lose the changes. I’ve witnessed a couple of different scenarios this year that drive me a little nuts:

  1. I’ll commit as soon as I’ve got it all working: The developer wouldn’t commit code for the first 3 weeks of a project, until he had virtually upgraded all of the system and built the foundations of the new project. Meanwhile, everyone else is sitting on their thumbs.
  2. I didn’t want to commit because I was afraid I’d mess up your stuff: I checked back in with a client 6 months after we last worked together. He stopped committing code after we left because he was afraid of breaking something we did, or having to merge code. Now he has to merge 6 months of stuff! It turns out the merge was relatively easy since no one else was working on the code at that time, but on a related pet peeve, hundreds of tests were now failing because he also wasn’t updating those.

It’s not that hard to reverse a commit if it’s really a disaster, but the odds are yours won’t be. Just get the code checked in already, will you?