Fail Fast Doesn’t Work In Programming

This idea came to mind when I was told that we needed to get our promotional feature (Urgency) out for mobile web. For those who use LivingSocial, you may have noticed the red page that give users extra discount on top of our great deals. That is urgency. I was given a dead line to get this feature out by morning.

Two things you need to know. First, we had urgency working before, but we turned it off for some reason. Second, there wasn’t any bugs and it was working when we turned off this feature. Given these information I faced a decision to either fully test it in development mode, which takes time and understanding of our different services, or believe in the given assumptions and turn on urgency without fully testing it.

As a developer under a deadline, I wanted to simply push out this features as fast as I could. People say fail fast and fail often, in order to figure out what works and what doesn’t.  Does it make sense to ship it and fail fast in my case?

Lets weigh the pros and cons. It’s great that LivingSocial has millions of  users and we can test if a new feature enhances our users experience quickly. However, a poorly designed or implemented feature can be the last straw for our users to never look back. As an user I would be extremely annoyed if I saw a flashy page saying I get a discount, but the promo code not working correctly during checkout.

This leads me to believe “fail fast fail often,” maybe true in terms of validating a new idea. However, it does not work when you’re testing out a new feature that can affect users purchasing decision. It’s far more important to make sure the core feature works as expected.

Standard

Managing Time For Yourself

One of the hardest things you face as a junior software developer is managing time. You constantly find yourself on a “quick” google hangout, a “simply” feature request, or a bug fix. Up until now, you haven’t said no to a “can you help me figure this out” request. You finally said no, because you have shit to do!

Don’t get me wrong, you probably believe helping each other is vital to your teams success. It’s important that you spend time knowledge sharing, and moving past roadblocks. It’s important to pair with senior developers. It’s a faster way to learn the codebase, as well as, better practices.

However, you can’t say yes to everything. You have deadlines you promised to meet. This requires time and effort so that you can write code that has test coverage. This means you need to focus on your work and get it done. You’re not helping anyone if you can’t hit your deadlines yourself.

Standard

Testing Is Necessary

Recently, I found a bug randomly by clicking around LivingSocial. When users mark vouchers as used,  the voucher wasn’t moved from “unused” to “all” vouchers. This was not the case, and my team would have never caught this bug unless someone happen to notice it in production.

All I could think was “the fuck? How long has this been broken for and how come nobody noticed it?” It turns out couple weeks back a service that mobile-web depends on changed! (In cases like this, SOA can be annoying and dangerous) Why? Because there was no test around this feature to alert us.

Whats the lesson here? If you’re making an external request, that code needs some testing love. We need to that we’re getting correct data back and the feature works as expected. Not following this procedure can lead to the external service changing and breaking code in our end.

Standard