Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Have you experienced real benefits from a 24 hour cycle? I've worked in environments like that and I feel like you're not actually gaining anything except a new layer of asynchronous communication requirements. It's not like you get more man hours after all.


Yep. Twice. Once for a big job ad scraping operation (we did this for ofccp compliance) where 24 hour dev enabled our scraping to not miss when our competitors would take 24-48 hours to re-tool when a targeted site changed. The second time was a webdev agency where we routinely were able to win business and delivery by promising to be done in 1/2 the calendar days as our competitors on the same bids. In the second situation I wouldn't have been able to hire enough people locally to just double the local man-hours anyway (small midwest town).


The first one is clearly a situation tailor made for 24/7 because your requirements change in such short periods. This is similar to how companies that offer 24/7 technical support benefit from 24/7 dev availability.

The second doesn’t seem to be an advantage for 24/7 availability. You would have achieved the same if you had hired the second team in a different country but in the same time zone as you. Arguably, with the more synchronous communication (I, on team A, have a question for someone on team B that’s blocking me can get the answer immediately instead of having to wait for my next shift) you may have been done even earlier.


> Arguably, with the more synchronous communication (I, on team A, have a question for someone on team B that’s blocking me can get the answer immediately instead of having to wait for my next shift) you may have been done even earlier.

What really worked was building something, showing the customer at 3pm, getting a change list and having all the changes done by 9am the next day. Also being able to do a design session and have all the prototype views done the next day really made customers happy. Another thing that was nice: we could have a bunch of stuff built at night and then test and fix it the next day (or vice versa).

You do have to assign tickets a little differently. You want avoid making tickets so big that a developer can't finish one in a day - or you can get into where there's lots of blocking. Regardless, I think the 24 hour cycle worked pretty well for us, and if I start another dev shop, I'll do it that way again.

A lot of the benefit was probably forcing everyone to do a couple of smart things: great CI, smaller tickets and complete work in one work day whenever possible. No dangling tickets. Avoid even having tickets where a developer can block another as much as you reasonably can. All of these things would have made a single timezone team better, too.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: