4 ms·

GitLab is a poster child of why companies don't publish any details. Deleted the production database and customer data? You could apologize and move on. There

GitLab is a poster child of why companies don't publish any details. Deleted the production database and customer data? You could apologize and move on. There should have been backups to restore from but clearly there weren't. The gitlab way: Go in great details about how there is no automated backup and the last one that was done manually 3 months ago doesn't work... and how there was no testing/staging environment to try the change before production... and how any intern could delete it the same way by accident on their first day. There's a reason companies don't publish gory details and internal discussion. At best there's nothing to gain from it and at worst it's highlighting incompetence and wrongdoing.

Jochim 6y ago
I think it's a good approach, it: 1) Works as a club for developers to get the time they need to improve processes and code. "Do you want to be responsible for the HN article about the incident this will cause?" would give most managers pause. 3) Gives customers the confidence that you'll let them know when issues that might affect their experience or data are occurring. 4) Proves to customers that you can fix these issues when they come up. 5) Makes people wonder what's going on in your competitors that they're not hearing. On the other hand you don't get to pretend the sun shines out your ass, but that's disingenuous and most people will see through it anyway, you only trick the people that also want to go along with you.
jcims 6y ago
That's definitely the pragmatic view and the obvious downsides are largely why this approach is so rare. Much like TFA I think there are things to be learned from that level of transparency and hope the experiments continue.
vidarh 6y ago
On the other hand, most of us knows there's a very real risk that things are duct taped together all over the place in companies whose services we depend on, but we don't know what the actual risks are. That's terrifying. In some ways it's terrifying to be able to see those risks too. But then we need to remind ourselves that those risks are there in companies that don't dare to tell us as well.

Jochim 6y ago

I think it's a good approach, it: 1) Works as a club for developers to get the time they need to improve processes and code. "Do you want to be responsible for the HN article about the incident this will cause?" would give most managers pause. 3) Gives customers the confidence that you'll let them know when issues that might affect their experience or data are occurring. 4) Proves to customers that you can fix these issues when they come up. 5) Makes people wonder what's going on in your competitors that they're not hearing. On the other hand you don't get to pretend the sun shines out your ass, but that's disingenuous and most people will see through it anyway, you only trick the people that also want to go along with you.

jcims 6y ago

That's definitely the pragmatic view and the obvious downsides are largely why this approach is so rare. Much like TFA I think there are things to be learned from that level of transparency and hope the experiments continue.

vidarh 6y ago

On the other hand, most of us knows there's a very real risk that things are duct taped together all over the place in companies whose services we depend on, but we don't know what the actual risks are. That's terrifying. In some ways it's terrifying to be able to see those risks too. But then we need to remind ourselves that those risks are there in companies that don't dare to tell us as well.