Tell HN: Slow Down
8 comments
We can't slow down.
Executives want to see numbers go up, even if it's a vanity metric like LOC or PRs merged.
It feels we're mostly building liabilities, rather than assets.
Management will later grind us to fix it all, as this will trigger a huge crisis as nothing works anymore, and we will have to do it and pretend they didn't create the problems themselves, so we keep our jobs, in the most optimistic scenario.
Companies with good tech leadership will thrive in that environment, but they are so few...
Executives want to see numbers go up, even if it's a vanity metric like LOC or PRs merged.
It feels we're mostly building liabilities, rather than assets.
Management will later grind us to fix it all, as this will trigger a huge crisis as nothing works anymore, and we will have to do it and pretend they didn't create the problems themselves, so we keep our jobs, in the most optimistic scenario.
Companies with good tech leadership will thrive in that environment, but they are so few...
> We do not need these crazy high release speeds with daily updates all over the stack
Although I like this, but I understand this is not easily achievable in companies where everyone is trying hard to grab the part of the market and AI FOMO and push by investors to release AI features
Although I like this, but I understand this is not easily achievable in companies where everyone is trying hard to grab the part of the market and AI FOMO and push by investors to release AI features
I'm not 100% what this is in reference to, but slowing down only helps if your reviewers are trustworthy. Open source runs on accumulated credibility, and credibility can be built specifically to be spent. You can't audit intentions.
>We do not need these crazy high release speeds with daily updates all over the stack, then you should just slow down and do better QA.
Too late now. Most places have been aggressively cutting QA for years. It's easier to mess up and apologize over doing it right.
Too late now. Most places have been aggressively cutting QA for years. It's easier to mess up and apologize over doing it right.
It depends what your doing? Some finance systems ive worked on prioritise stability over release cycles so do things like not release fridays or last week of month unless impact can be guaranteed
> The number of supply chain attacks and the blast radius as a result of these is ever increasing
Holy vague post... can u be specific?
Holy vague post... can u be specific?
This isnt the problem, the problem is open source software became a status marker/way to build a company.
This doesn't scale. Reviewing all of this code by all of the potential users is just asking for it, the bulk of them did not have the resource to write the module/library in the first place so they most likely will not have the resources to review everything they ingest.
I'm trying to imagine Linux with not one distribution but several thousand each of which could become malicious at the drop of a hat. In the longer term this will not work. All of these systems can only work in a world where there are no bad actors and where you implicitly trust the source.
Please improve curation. The next supply chain bug may well be 'the big one' and I'm pretty sure that various nation states are aiming to achieve that kind of capability now that there are ample proofs of concept out there. We need fewer points of distribution with better curation and far stricter review before inclusion, something along the lines of the Linux Kernel.
We do not need these crazy high release speeds with daily updates all over the stack, then you should just slow down and do better QA.
Reliability comes from the ability to invest the time review and increase understanding, not from the ability to release at breakneck speed, use your downstream as QA and then to fix things when you get them wrong. If it was coded today the world does not need it until tomorrow or even the day after tomorrow. Having a 'hot path' from your development environment to release that is fast also has the potential to export any compromise of your environment to your releases. More so if you accept external contributions to your code.