Agile Zone is brought to you in partnership with:

Justin Bozonier is the Product Optimization Specialist at GrubHub formerly Sr. Developer/Analyst at Cheezburger. He's engineered a large, scalable analytics system, worked on actuarial modeling software. As Product Optimization Specialist he is currently leading split test design, implementation, and analysis. The opinions expressed here represent my own and not those of my employer. Justin is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

TDD for Business Value

04.08.2013
| 2697 views |
  • submit to reddit
A New Hope Software Craftsmanship, SOLID principles, eXtreme Programming, the list of all the “best practice” guides I’ve learned over the years goes on and on. They are all extremely valuable to me. They also need to make room for a new style of development being ushered in by the ideas expressed in The Lean Startup. The best way to label it is as “the way Bozo is coding for now”.

What exactly do am I talking about? Temporary code written fast and with little thought. Code meant to elicit learning and then promptly discarded and removed from production. Wait what? Let me take a step back.

I’ve been using a new process for split testing features. It flows like this:

  1. Formulate a hypothesis AKA have a testable opinion. I am nothing if not opinionated.
  2. Design a test. ie. Let’s move this thing here, and that then there. List independent variables, dependent variables, covariates, expected benefits AKA $BLING$ Make an assumption that a certain segment of my customer base is representative (enough) of my full customer base.
  3. Code up something that only works for that segment… maybe it even only half works. Fuck any kind of automated testing unless it makes this step faster.
  4. Test what’s been written and decide if it’s “Good Enough” to get us reliable results.
  5. Release the test to production
  6. Once the test is over, delete all the code from production.


Why Is This Magical?

Step three is the one that’s gonna make me sound like an unknowing ass hat. Allow me to explain:

If you’re going to throw away code and aren’t going to need to maintain it the rules of the Agile game change dramatically.

Why do we write automated tests? We accept that the slight cost increase now is worth it in the long run because the code will be around for a while and fellow team mates will need to interact with it. tl;dr It’s a way of keeping our costs low. Great. Seriously.

So once we accept that this code will only live in production for a day and I can reasonably say no one will have to understand my code now why do I write automated tests? I don’t.

Also, notice step two. If you severely limit the customer segments you’re targeting it means you can take a bunch of shortcuts like:

Someone please ask me, “But what if there’s A LOT of code for the test?” Two things:

  1. Your test is probably too damn big and testing more than isolated changes. (Notice the italics. #GuidelinesNotSteadfastRules)
  2. Remember step three? You wrote that code in a shitty unsustainable manner… BUT. You’ll be able to rationalize taking the time to refactor after this. Lemme tell you why.

Know The Value of Your Work

You just developed, shipped, and validated the value of some code you are planning to put into production within two days. You now know how much money the feature makes your business and that means you also now know how much money your company will lose every time the feature breaks. Suddenly you’re not just pushing out features because you’re bored or trying to keep your team from looking idle, you’re pushing out features because they make your company more money.

This is the new TDD guys. This is Red, Green, Refactor for business value. 

  1. Red- Think about what you’re doing enough to understand how you can test it.
  2. Green- Find out it makes you money and delete the code.
  3. Refactor- Write the code well and in a disciplined manner knowing that you’ve proven it’s worth the time.

Not Worth Testing

If a change is so small it isn’t worth testing to see if it effects anything then WTF are we doing here? Who the hell is prioritizing that feature? Push back and bring this up. Branding might be a reason. I’m not sure how I feel about that. I can sympathize with design and… yeah. Separate blog post.

If a change is such a sure thing that you KNOW it will bring in major money then the cost to test it is probably insignificant given the long term value.

Have You Actually Tried This?

Yes.

Published at DZone with permission of Justin Bozonier, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)