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:
- Formulate a hypothesis AKA have a testable opinion. I am nothing if not opinionated.
- 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.
- 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.
- Test what's been written and decide if it's "Good Enough" to get us reliable results.
- Release the test to production
- 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:
- Only run this on non-mobile browsers
- Only run in Safari
- Only run if this user came from page "http://fookyou.com/fookme"
Someone please ask me, "But what if there's A LOT of code for the test?" Two things:
- Your test is probably too damn big and testing more than isolated changes. (Notice the italics. #GuidelinesNotSteadfastRules)
- 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.
- Red- Think about what you're doing enough to understand how you can test it.
- Green- Find out it makes you money and delete the code.
- 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.