Hacker News Reader

Comment by bmelton | Hacker News Reader

If Kevin broke the site, it's a process problem. Kevin didn't break the site, he introduced code that might have broken the site, and the lack of tests to have detected the it broke the site. Jane then peer reviewed the code that might have broken the site and approved it. Bob then failed to notice that the site was broken during QA. The QA environment was apparently configured differently enough by Taylor that the site could appear working in dev and QA, and pass unit and functional tests without exploding until it hit production.

The team broke the site.

View on HN

As true as this is, unexpected problems happen. Kevin may be the only one that can fix it, or at least be able to fix it a lot more effectively than others. The issue might not be Kevin's fault (i.e it's really a process problem), but being able to talk to him immediately (or at least know his schedule) will go a long ways in getting the issue resolved in an acceptable time frame.

Nothing against remote work, but knowing everyone's typical working hours makes things run a lot more smoothly.

Kevin's available hours should be common knowledge, or easily findable in a system of some sort, ranging from text file to excel sheet to Exchange to massively overpriced time-tracking software.

Doesn't really help to know peoples hours. If they're not overlapping with yours then you have a potentially crazy overhead on time it takes to get responses to issues that could hold up your work completely.

That's a fundamental problem of teamwork. This also happens when the coworker sitting right next to you, working the same hours, has a higher-priority task than the one you're waiting for.

It absolutely does, although in my personal experience far, far more rarely. And even if that person was sitting remotely at their own hours you’ld then have to wait for them to get ”to work” and then do that higher-priority task and then get to your request so the overhead is still waaaaay bigger.

If your process cannot revert a breaking change with a figurative snap of fingers, the process is broken. It is like driving a car with no brakes.

About the only time where I've seen this fail is if it was a publicised feature launch that was way premature.

And when it's the build server itself that's broken? No process can account for every possible edge case, and you need to have flexibility to handle the unexpected.

At some point problems reach the "Call Kevin now, I don't care what time it is" level. Your processes should enable anyone to handle problems that are not at this level.

if the build system is broken, then no new code gets built to roll to production. Your build system has no resiliency in terms of having more than one, or ability to roll back? Do you even have version control implemented along with a mature change control process, with automation and monitoring in place?

And what happens when Kevin is on vacation or is sick or quits?

This was in response to Practical Tip #1: "People don't have to say when they are working."

I'm arguing that this tip is harmful. I should know he was on vacation, and thus have a plan in place to handle anything that might come up while he's on vacation. If I'm completely in the dark about when he's working, things are going to be a lot more difficult.

Vacation / Sick time is a bit different than needing to run errands till 10am, either shifting the working day round a bit or spreading the time out over the next days or week etc.

Doesn't hurt to check in when you're available again as a courtesy but the benefit is NOT having to get permission to do something like this up front.

If you're remote as an employee then presumably the company has process around holidays and stuff that would be followed. If you're a freelancer then part of what stops you, and your client, from being fined by HMRC (in Britain) is setting your own working hours and days.

The main bit of process missing here seems to be the requirement that the developer of a given feature is at work (or at least on call) when it's deployed and has it's first full day of usage (or whatever makes sense for the particular type of application). Don't deploy on Friday afternoon, it's better for everyone to wait until Monday morning. Certainly don't deploy major feature work just before going on holiday, etc.

Additionally, if Jim had configured the backups properly the site could be reverted to a stable build. A lot of measures could prevent these situations.

Reply on news.ycombinator.com