In 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?
I found that quite humbling. I thought I was a lot better at writing secure code than that.
The statement was about the difficulty of creating _correct_ code. Agreed security is important. So is performance, memory usage, etc - and we're not talking about those either.
Original comment said that "Producing correct code is insanely difficult". I agree with them.
And not all code is the same. To a huge degree - most things are pretty straightforward, and the hard stuff is usually a minority of the whole.
Correct code might not be sufficiently tested, it might waste memory, it might do dumb things with the wrong data structures, it might be terribly factored, it might be commented in sanskrit - and yet it can still be "correct". Don't muddy the waters by bringing in all these other factors. Those are not correctness, even though it might be something that you (and I) strongly desire, or things that are necessary to ship with. Correctness is not "done".
And I agree that any code released into the wild should be as secure as you can make it. Though a scientist running a sim on their desktop might not be remotely concerned at how secure their fortran code is.
Isn’t the admittance that “of course most products are highly imperfect” more supportive of writing correct code as being difficult than not?
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 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.
For the kinds of systems I work on, loose coupling + high cohesion is mandatory, but building reliable systems is still difficult and time consuming regardless.
That blockchain project I mentioned wasn't architected well in the beginning and it was a nightmare to work with; it had to be rewritten because it was literally impossible to add new features on top (in a reliable way); nobody could do it, even the people who were there since the beginning couldn't explain how it was working. Making it modular allowed us to make it reliable and extensible but each module was still difficult to work on in the sense that every feature required careful discussion and debate with team members because so many tradeoffs had to be considered.
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!