3 ms·

Oh god. I'm a developer for a fantasy soccer, football etc. site and this is my ongoing nightmare. Fantasy sport provides some interesting challenges as a deve

Oh god. I'm a developer for a fantasy soccer, football etc. site and this is my ongoing nightmare. Fantasy sport provides some interesting challenges as a developer, but the fact that you are operating with deadlines and windows outside of your control and server loads that vary by a factor of 5-10 in minutes is... challenging. If your site stumbles at the wrong moment (and we have on several occasions) you are basically screwed. You can't call FIFA or NFL and ask them to delay the event for a few hours while you put out a fire, or finish developing that new feature. I can feel my stress level rising even as I'm writing this...

peterwwillis 12y ago
Relax. You are not the person responsible for the site being up. That's Ops, QA, and support's job. All you need to do is provide a working product ahead of time to the other teams to load test it and figure out stopgaps for any holes found. You can of course expect to be working at launch time, crushing random bugs and pushing fixes to production. But those should be minor issues. If everyone else has done their job, you will never have a Yahoo-esque outage, and you certainly shouldn't be held responsible. For the downvoters who don't find this comment helpful, I worked for four years in CBS's fantasy sports operations team, handling hundreds of thousands of hits per second (dynamic content) and tens of gigabits of sustained traffic on launch days, and we never blamed the developers for an outage. (We did, however, have them on hand to look at problems)
- yummybear 12y ago
  Well we're a small shop, so I am Ops, QA and support ;)
  - peterwwillis 12y ago
    Well then, i'm sorry to hear that! But still, try not to get stressed if you have problems doing the job of 10 different people. My suggestion is to focus on making the application robust against errors and invalid data, and determining the performance limits of various parts of your application stack, then making sure you allocate headroom for the expected traffic well before the event - none of this automatic scaling business.

peterwwillis 12y ago

Relax. You are not the person responsible for the site being up. That's Ops, QA, and support's job. All you need to do is provide a working product ahead of time to the other teams to load test it and figure out stopgaps for any holes found. You can of course expect to be working at launch time, crushing random bugs and pushing fixes to production. But those should be minor issues. If everyone else has done their job, you will never have a Yahoo-esque outage, and you certainly shouldn't be held responsible. For the downvoters who don't find this comment helpful, I worked for four years in CBS's fantasy sports operations team, handling hundreds of thousands of hits per second (dynamic content) and tens of gigabits of sustained traffic on launch days, and we never blamed the developers for an outage. (We did, however, have them on hand to look at problems)

yummybear 12y ago
Well we're a small shop, so I am Ops, QA and support ;)
- peterwwillis 12y ago
  Well then, i'm sorry to hear that! But still, try not to get stressed if you have problems doing the job of 10 different people. My suggestion is to focus on making the application robust against errors and invalid data, and determining the performance limits of various parts of your application stack, then making sure you allocate headroom for the expected traffic well before the event - none of this automatic scaling business.