4 ms·

Having never had a "normal" job per se (okay, I bagged groceries for a year when I was younger), I still find it hard to believe that it can take two weeks just

by tdavis 18y ago

Having never had a "normal" job per se (okay, I bagged groceries for a year when I was younger), I still find it hard to believe that it can take two weeks just to get something deployed. Maybe one day I'll finally truly believe all the stories I've heard -- two-week deployments, meetings about future meetings, etc. For now, some part of me still believes it's simply implausible and everyone is engaging in hyperbole...

trapper 18y ago
It's not abnormal. In rails I have deployed to a customer in 12 hours, starting from scratch. I was using my own framework though. In gwt, I have done this in ~24 hours. These weren't simple apps either, not just scaffolding, but had complex user interfaces.
- tdavis 18y ago
  I wasn't referring to task difficulty, just the extreme time delay between when something is ready and when it is put into production.
  - trapper 18y ago
    I was referring to development & production deployments in both examples.
  - jodrellblank 18y ago
    The delay is between when it's first claimed finished by the author(s) and when it's agreed to be ready by everyone involved. After that it can be deployed instantly... I guess it would be possible to note in a bug tracking app "we would have deployed here" and then see how many, and what kind of bugs were found between then and actual deployment, which checks found them, and whether any of those were rollback-causers. That would give an estimate of how much good the checks did in each case, and a way to choose which checks are ineffective for their cost. (Ish - some checks may only trigger once, ever, to be priceless).
neilk 18y ago
Sure. It is often due to dysfunction, but it can even happen to good teams. Imagine you have to fix a simple bug, like the description of an option in an HTML page. Imagine that: the codebase is a bajillion lines of Java or C++ that no one person truly understands any more. Imagine that: fucking up is considered bad. Maybe you're protecting important user data, or maybe it's just code for the online store, and even an hour of downtime can wipe out the day's profits. The team is so big that your feature is scheduled for deployment along with four or five others this week. As usual, management has skimped on QA so there are not enough of them to go around. Also, QA was added late, so there's no fast automated test suite. It takes them a full week of manual and semi-automatic testing to go through all regressions. After that week of testing in development is over, then it goes to staging, where it's tested with real live data and staging subsystems. At least somewhere in this, something breaks (something is always breaking) and a fix is produced. Then the new build is tested all over again, with the basic smoke tests as well as any test suites that are applicable to that unit of code which broke. This is causing another trainwreck because we promised feature X to client Y by end of the month. What do we do? Emergency team meeting! Let's rebalance the work schedule. Meanwhile, your change, which just a simple HTML fix, languishes as this build goes into its second round of testing. Oh, and did we mention that you have to have submitted your code in time for translation into six languages? I'm afraid that the French translator did not produce a satisfactory translation in time, so we're going to have to hold your change back. Can you revert this and put it in next week's build? Thanks.
kscaldef 18y ago
I've waited a year to launch something. Then I quit.

by tdavis 18y ago

trapper 18y ago

It's not abnormal. In rails I have deployed to a customer in 12 hours, starting from scratch. I was using my own framework though. In gwt, I have done this in ~24 hours. These weren't simple apps either, not just scaffolding, but had complex user interfaces.

tdavis 18y ago
I wasn't referring to task difficulty, just the extreme time delay between when something is ready and when it is put into production.
- trapper 18y ago
  I was referring to development & production deployments in both examples.
- jodrellblank 18y ago
  The delay is between when it's first claimed finished by the author(s) and when it's agreed to be ready by everyone involved. After that it can be deployed instantly... I guess it would be possible to note in a bug tracking app "we would have deployed here" and then see how many, and what kind of bugs were found between then and actual deployment, which checks found them, and whether any of those were rollback-causers. That would give an estimate of how much good the checks did in each case, and a way to choose which checks are ineffective for their cost. (Ish - some checks may only trigger once, ever, to be priceless).

neilk 18y ago

Sure. It is often due to dysfunction, but it can even happen to good teams. Imagine you have to fix a simple bug, like the description of an option in an HTML page. Imagine that: the codebase is a bajillion lines of Java or C++ that no one person truly understands any more. Imagine that: fucking up is considered bad. Maybe you're protecting important user data, or maybe it's just code for the online store, and even an hour of downtime can wipe out the day's profits. The team is so big that your feature is scheduled for deployment along with four or five others this week. As usual, management has skimped on QA so there are not enough of them to go around. Also, QA was added late, so there's no fast automated test suite. It takes them a full week of manual and semi-automatic testing to go through all regressions. After that week of testing in development is over, then it goes to staging, where it's tested with real live data and staging subsystems. At least somewhere in this, something breaks (something is always breaking) and a fix is produced. Then the new build is tested all over again, with the basic smoke tests as well as any test suites that are applicable to that unit of code which broke. This is causing another trainwreck because we promised feature X to client Y by end of the month. What do we do? Emergency team meeting! Let's rebalance the work schedule. Meanwhile, your change, which just a simple HTML fix, languishes as this build goes into its second round of testing. Oh, and did we mention that you have to have submitted your code in time for translation into six languages? I'm afraid that the French translator did not produce a satisfactory translation in time, so we're going to have to hold your change back. Can you revert this and put it in next week's build? Thanks.

kscaldef 18y ago

I've waited a year to launch something. Then I quit.