I am quite a seasoned dev myself, and “insanely difficult” is not what I consider writing code to be. Perhaps if you have a crazy coupled system that is very hard to reason about, or you’re going about things in a very cowboy fashion. Or perhaps you’re writing under very challenging constraints.
Care to explain the circumstances/context that you mean?
I work with distributed systems. Try producing correct code with table sharding, replication, cache, realtime updates (targeted/efficient), distributed processing, streaming in batches without missing any rows...
When I worked with blockchain before, that was another level because each node had to talk with thousands of other nodes; each running different versions of the code and they had to propagate messages throughout the network in a secure and scalable way without missing any nodes or reaching the same node twice (spam vulnerability) so your code is basically talking to different versions of itself which feels a bit like recursion, but harder and with a network between which adds latency and errors; and you can encounter tricky issues like message storms among others where the nodes keep bouncing and replicating a message between themselves. Or if any kind of propagated processing doesn't deduct tokens, then that's a massive spam vulnerability. Also, if the peer-discovery algorithm is structured, then the network is vulnerable to eclipse attacks. Also, most parts of the code had to be fully deterministic and idempotent or else some nodes could fork off the network. Stamping out all non-deterministic, non-idempotent logic is hard work, especially when you have to do it across multiple distinct nodes running on different machines operated by different people! Paradoxically, some parts of the code actually benefited from being non-deterministic like the P2P networking and peer discovery logic since that made it harder to game/carry out eclipse attacks. So you need deep, nuanced knowledge to get it right.
I mean … trees, what you’re describing is a challenging situation. But also, you don’t have to take that all on at once all the time. You ought to have corners of your code where you have guarantees and invariants you can trust that make your life easier. At least I would hope.
Also you made a general statement about writing correct code being insanely hard. I mean, writing hard code is hard, but many if not most of the things we do in this profession are not in that category. And most of the correctness we need to achieve isn’t insanely hard. Agreed that there are of course areas where the confluence of challenges can be extremely challenging.
My experience is that for a lot of complex systems, there are many exception cases which need to be handled, many interpretations, gaps and sometimes contradictions in the spec. It just takes a lot of effort and a long time to handle all possible cases.
Sometimes even something which sounds really simple, isn't simple at all once you consider all the possible formats, modes of interaction and all the things which could go wrong.
So yes, "for a lot of complex systems" writing some of that code can be hard. Writing code in general, isn't "insanely hard".
You want to write the next Google Spanner - probably challenging. You want to write another instagram - probably mostly straightforward with some intense challenge peppered around.
We all have to deal with exception cases, ambiguity, etc. That's not "insanely hard" - that's just the expectation for this career. No different (easier?) than engineering, etc.
3) is not possible given the other two, since there is no worldwide consensus on what is a valid name or address. Often developers over-constrain the inputs without good reason.
Imagine a very complex piece of software, now imagine a venn diagram where every feature is a bubble. Now imagine those bubbles overlapping by the number of users who use/have-access-to the feature.
Any of those little junctions between features could very well have <10 users even on multi-million users pieces of software. Now every one of those little possible cross-sections in the venn diagram is another possible state the software can be in and that needs to be tested.
In the software I work currently we have one of such case, a combination of 3 different features that almost no users use in conjunction, but if they do it breaks the system. I am aware of it, my manager is aware, the product owner is aware, the fix is not trivial (in fact it would require rewriting large portions of the system).
It just stays there and we have monitoring and customer-support manually handling it. The product is fundamentally not correct (in fact the correct behavior is not even defined), yet it still works for 99.99% of the users.
Practical example? I have ran multiple times in multiple different products (even ones I worked) where if you login with Google/Apple/Whatever that makes your account completely borked to be used with SAML/OIDC if you get invited into one later. You basically need to call support to ask them to remove your user and be invited again. All those software were, by definition, not correct.
You can definitely engineer situations where you make your life far harder. Combinations of mutually incompatible feature flags is a great example. I get that some orgs just stroll down this road with disregard for the costs, but that's an aside.
Even in the presence of this sub-optimal situation, I would argue you can probably carve out areas where you're able to reason about the logic you're adding. If you can't - then that's a very strong signal your codebase is factored poorly.
This still doesn't counter the opinion that in general getting correctness right is "insanely hard". It certainly can be in some circumstances, like you're alluded to here. I would say step 1 is probably making changes to reduce the complexity you're dealing with. Or perhaps find a different gig!
The tidal wave of reports will continue, until reporters stand to lose real money from submitting bad reports.
Reporters that submit useful, quality reports, should not only get their money back, but also a dividend on the money taken from low-quality reporters.
ostriches hiding their heads in the dirt to escape danger is a common allusion for someone or something irrationally ignoring real looming danger and just denies the existence of the danger instead
in this case it would be organizations refusing to adapt more rigorous quality tooling alongside the rate of release, similar to the footgun allusion
as a fun sidenote, it does look like the ostrich sticking its head in the sand was a mistaken inference by the Romans and in actuality they do that to build and maintain their underground nests
> Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo. Accordingly, I recommend against using Rust for writing GNOME software.
It didn't seem like the article was really about Rust, honestly.
I must say, I had this thought. While everyone thought AI written code will inevitably lead to slop, bugs and security issues, I had the feeling the exact opposite happens. I can task an AI agent with striving for the quality metrics I want to see, and it will always work along them. No fatigue that leads to errors, almost no oversights even in more complex systems, etc.
This may actually be the time where it becomes feasible to create high quality software with reasonable (human) effort.
What we are seeing with AI generated incident reports causing issues is maybe mostly an impedance mismatch between people who have fully adopted AI and people /projects who haven't.
> any use of Cargo to download dependencies dramatically increases supply chain security risk.
> Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo.
That's what an ostrich would say. How is your manual alternative to manage supply chain any better than this explicit one where transparency is standardised?
> I don’t want to downplay the severity of security issues either.
That's exactly what you're doing
> Security vulnerabilities are not even the biggest digital security threats ... a distant third place
Downplaying the 3rd biggest issue
> Security bugs are just bugs, and they’re not necessarily more important than other bugs.
23 comments
[ 183 ms ] story [ 859 ms ] threadIn fact, for many complex projects, it's essentially impossible, even with AI.
Eventually, you get to a point when you have every feature you could possibly want but the list of tradeoffs is long and yet not worth trimming.
Care to explain the circumstances/context that you mean?
When I worked with blockchain before, that was another level because each node had to talk with thousands of other nodes; each running different versions of the code and they had to propagate messages throughout the network in a secure and scalable way without missing any nodes or reaching the same node twice (spam vulnerability) so your code is basically talking to different versions of itself which feels a bit like recursion, but harder and with a network between which adds latency and errors; and you can encounter tricky issues like message storms among others where the nodes keep bouncing and replicating a message between themselves. Or if any kind of propagated processing doesn't deduct tokens, then that's a massive spam vulnerability. Also, if the peer-discovery algorithm is structured, then the network is vulnerable to eclipse attacks. Also, most parts of the code had to be fully deterministic and idempotent or else some nodes could fork off the network. Stamping out all non-deterministic, non-idempotent logic is hard work, especially when you have to do it across multiple distinct nodes running on different machines operated by different people! Paradoxically, some parts of the code actually benefited from being non-deterministic like the P2P networking and peer discovery logic since that made it harder to game/carry out eclipse attacks. So you need deep, nuanced knowledge to get it right.
Also you made a general statement about writing correct code being insanely hard. I mean, writing hard code is hard, but many if not most of the things we do in this profession are not in that category. And most of the correctness we need to achieve isn’t insanely hard. Agreed that there are of course areas where the confluence of challenges can be extremely challenging.
Sometimes even something which sounds really simple, isn't simple at all once you consider all the possible formats, modes of interaction and all the things which could go wrong.
You want to write the next Google Spanner - probably challenging. You want to write another instagram - probably mostly straightforward with some intense challenge peppered around.
We all have to deal with exception cases, ambiguity, etc. That's not "insanely hard" - that's just the expectation for this career. No different (easier?) than engineering, etc.
1) person's name 2) their address 3) their email address
This form must
1) meet or exceed WCAG AA 2.1 2) handle people from all over the world 3) only allow valid inputs
If you've never done this before you will think it easy. If you have you will know that it's nearly impossible. This is web development btw.
I've also had registered domains turn the box red with "Please enter a valid email address" as if it needed to end in .(com|org|edu|gov)
Any of those little junctions between features could very well have <10 users even on multi-million users pieces of software. Now every one of those little possible cross-sections in the venn diagram is another possible state the software can be in and that needs to be tested.
In the software I work currently we have one of such case, a combination of 3 different features that almost no users use in conjunction, but if they do it breaks the system. I am aware of it, my manager is aware, the product owner is aware, the fix is not trivial (in fact it would require rewriting large portions of the system).
It just stays there and we have monitoring and customer-support manually handling it. The product is fundamentally not correct (in fact the correct behavior is not even defined), yet it still works for 99.99% of the users.
Practical example? I have ran multiple times in multiple different products (even ones I worked) where if you login with Google/Apple/Whatever that makes your account completely borked to be used with SAML/OIDC if you get invited into one later. You basically need to call support to ask them to remove your user and be invited again. All those software were, by definition, not correct.
Even in the presence of this sub-optimal situation, I would argue you can probably carve out areas where you're able to reason about the logic you're adding. If you can't - then that's a very strong signal your codebase is factored poorly.
This still doesn't counter the opinion that in general getting correctness right is "insanely hard". It certainly can be in some circumstances, like you're alluded to here. I would say step 1 is probably making changes to reduce the complexity you're dealing with. Or perhaps find a different gig!
Reporters that submit useful, quality reports, should not only get their money back, but also a dividend on the money taken from low-quality reporters.
in this case it would be organizations refusing to adapt more rigorous quality tooling alongside the rate of release, similar to the footgun allusion
https://www.mcgill.ca/oss/article/did-you-know/ostriches-do-...
> Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo. Accordingly, I recommend against using Rust for writing GNOME software.
It didn't seem like the article was really about Rust, honestly.
This may actually be the time where it becomes feasible to create high quality software with reasonable (human) effort.
What we are seeing with AI generated incident reports causing issues is maybe mostly an impedance mismatch between people who have fully adopted AI and people /projects who haven't.
That's what an ostrich would say. How is your manual alternative to manage supply chain any better than this explicit one where transparency is standardised?
> I don’t want to downplay the severity of security issues either.
That's exactly what you're doing
> Security vulnerabilities are not even the biggest digital security threats ... a distant third place
Downplaying the 3rd biggest issue
> Security bugs are just bugs, and they’re not necessarily more important than other bugs.
Downplaying the danger.