Hacker News Reader

Comment by gbuk2013 | Hacker News Reader

gbuk2013

> 2. Every code change must be reviewed

At a couple of places I worked at this was a hard compliance requirement: there had to be at least one review by a human to guard against an engineer slipping in malicious code (knowingly or otherwise).

View on HN

Yeah, there's whole industries where you simply cannot operate without enforcing this. The author's view is pretty narrow, both on this front and on the other points.

The author mostly write about average startup work, not about industries or more constrained environment. A good example of this is the sprint thing: you can do whatever pace you want when you work on your own product that is a web product, but as soon as you work on something with hardware or marketing, you can't just use random deadlines.

Conversely, feature flags can create annoying issues due to compliance requirements.

I worked on an underwriting system where we had to be able to explain the reason for a decision. This meant that you needed to have on file both the state of the flag and the effective logic at the moment in time that a line of credit was offered to a customer.

They're useful, but not necessarily simple.

Right, they add risk both in terms of inadvertently being turned on / off and also in terms of permutations of possible system configurations that need to be tested. Less of a problem for well engineered systems with good deployment practices but it’s rare to come across these mythical things. :)

It depends a lot on the domain. I've mostly worked in high compliance/regulation worlds. It can be kind of stifling, honestly, but "oops maybe we had the feature flag turned on" is not going to cut the mustard.

Most startups can ignore all that at least until they get to a scale where "run out of money, go bust" is not the biggest risk to their business :)

This is very true and is exactly why there is no magic right answer other than “it depends”.

There are different stages of company lifecycle, different industries, different regulatory environments etc.

The processes put in place always have a cost - if picked appropriately it is worth paying, otherwise it is a waste that can hurt or even kills a project. This balance is the “art” of the job that I personally am only starting to probe around at my level and so it is still quite interesting. :)

I was going to make the same observation - typically this will be defined in your secure development policy or similar, and be part of your ISMS controls for whatever frameworks you're aligning to.

It's possible this is more relevant in B2B contexts than B2C

Luckily, gemini catches a good amount of errors in PR reviews, less need for manual review unless you need to double check if the code structure and architecture is sane.

Until it doesn't, you f up but at least it apologizes later

Depends on how good the human reviewers are. It's hard to give a thorough code review, you need to understand the code and requirements, pull the changes locally, manually test the PR, think about security, readability, catch line level bugs like bad conditionals, but also think about the overall structure (classes, patterns, systems). But this requires a lot of effort, especially with larger PRs and it's easy for things to slip through. Nothing is perfect, but you can think of AI review like a supercharged linter, it might not suggest an alternative approach, but it will point out some glaring omissions or unhandled exceptions, etc.

Reply on news.ycombinator.com