Comment by tharne | Hacker News Reader

Comment by tharne | Hacker News Reader

Parent Full thread

> The amount of people on HN nowadays that are okay with getting nothing useful done is striking.

You're mistaking the role of a mature company. Unlike a startup, in a mature company there are a ton of customers relying on your product and making sure you don't f*k up their business with a mistake or careless change is much more important than building cool new stuff quickly. You don't want your bank "moving fast and breaking things". There are a whole lot of industries where stability and consistency are an order of magnitude more important than fast innovation. This may not be as sexy or fun as rapidly prototyping some MVP, but it's how a lot of important stuff that runs the world works. To this end, a large org may not be everyone's cup of tea.

Yes, there will be some waste and bureaucracy at any large org, but that's not the same as a place full of people "that are okay getting nothing useful done". If anything, it's the established boring companies that are doing something useful (even if that something is not sexy or exciting), while a lot of startups are just burning through someone else's money designing things that no one really wants or needs.

Exactly. When you're a $1T+ company, nothing "just takes two weeks" to implement. What if your tiny change has an unforeseen side effect that takes down a critical auth system resulting in a revenue loss of $10M/minute. Are you going to take responsibility? What are you going to write in that postmortem? What if your change infringes on someone's patent or causes some other regulatory compliance related issue and the company gets sued? Your $BIG_COMPANY is not putting this change request through ultra-scrutiny just to frustrate you.

First, the team needing to do the work has about 10X as much work waiting in their queue than they can possibly do given their staffing. So your request either has to be more important than the existing work, you need to get a VP to expedite it, or you need to wait. It's not like there's an engineer just sitting there picking his nose browsing Facebook waiting for work. And even if you just yeet them a patch, they will need to set aside engineering time to review that patch, so back of the queue it goes, too.

Second, that work needs to go through (sometimes multiple) code reviews, have unit and integration tests written, and be able to show those test passing more than once, it needs to get reviewed by legal so it doesn't expose us to legal liability, it needs to get reviewed by security so my 9 year old can't use it to get a root shell, it needs to get reviewed by privacy/data protection so we know it's not leaking some user's personal information, it needs to get a systems review so we know it won't disrupt other critical revenue-generating services. I mean, what are you expecting, just type the code in, run a few tests, any yolo it into production?? No way.

A fantastic and experienced reply. OP, please listen to this

> it needs to get reviewed by legal so it doesn't expose us to legal liability

I'd like to understand this. How does a legal team do a code review that ensures a code change doesn't expose the company to legal liability?

Usually it is more like "legal needs to be notified anytime third party dependencies are updated with a list of the licenses to make sure we aren't accidentally using GPL or proprietary code".

Other times legal gets involved earlier at the planning stages in case a feature or product falls under HIPAA or similar regulatory framework.

Actual code itself doesn't cross legal's desk anywhere that I know of.

The setup I saw is: there is an IP plan that documents whatever 3rd part IP you are using in your product (open-source or not). Someone has to sign-off on that plan, and sometimes developers do self-attestation that they have not deviated from it. Additionally, the binaries are scanned for certain things to avoid escapes of pre-release information, etc.

Our legal team has to review parts of our application to ensure we were in compliance with certain government programs such as ITAR and EAR. They don't do code level review but they do review business processes, UI's and messaging to make sure we're in compliance.

There is no code review by legal. There is a talk, usually multiple talks, between legal representatives and the engineers + manager delivering something. It's the engineers and manager job to explain what the piece of work will do and help legal understand its implications so they can gather knowledge and come up with their assessment given their skills in Law.

I think you read it too literally, legal will review what is the impact of some changes in compliance and so on but you, as an engineer, is responsible to translate what the code/feature/system is doing to something that legal can understand and reason about, it's part of your job if you are anywhere senior+ level.

I had to interact quite a lot with legal in my past couple of jobs, it wasn't ever an issue because the legal department seemed to be staffed with smart people that would understand what I was telling them, or would ask relevant questions to clarify their understanding, it's a two-way street, not a button to push on the PR to "ask for legal review".

Let's also not forget the value of having a person sitting there doing just the bare minimum needed to have some familiarity with where things are and what does what... so if something does blow up (and it will), (s)he can instantly step in and take emergency measures to restore service.

It's called 'reserve capacity', and some people think it is helpful

> If anything, it's the established boring companies that are doing something useful (even if that something is not sexy or exciting), while a lot of startups are just burning through someone else's money designing things that no one really wants or needs.

To be honest, SME remain the economic backbone of most modern countries and the size of SME still allow them to operate somewhat effectively. Most large companies are either slowly drifting to irrelevance, surviving on a steady diet of acquisitions from teams who could previously achieve things or milking a business line they established when they were smaller and somewhat nibble. Large companies successfully growing by building what you call important stuff without acquiring are the exception.

Working backwards from your label, what signs leading up to Facebook's recent outages could we have used to evaluate them as being or not being a "mature company"?

I think, perhaps, that being siloed, bureaucratic, large, profitable, and management heavy are not the best or only qualifiers of "maturity".

Reply on news.ycombinator.com