> (NB: I'm deliberately not saying complexity, because the code doesn't necessarily get more complex)
the context was already lamenting the duplication of code, which in itself is a form of inconvenience, as you kinda admit; because generalizing it to "complexity" would be forgetting the possibility of adding resilience, and adding stuff doesn't necessarily mean anything gets more complex - just more entrophic, the stuff added may not be optimal.
> But writing a .... is a huge lift.
And also the only way to minimize the security risk; by rewriting/auditing/formalizing.
Ultimately the risk transformation is exponential; don't roll your own crypto, don't DIY authentication/authorization, don't risk your own inconvenience and assume security.
However the opposite, to use all the "agreed"-upon code, introduces a near similar surface area of risk, simply spread across more vectors. And because the vectors are spread, and the system is more complex, the dissolution of responsibility leads to the opportune laziest option - patching code together, trusting it works.
it would be wise to question why this convention is so normalized.
Just to put it on the record I am happy to acknowledge that duplication is an inconvenience as well as a security issue.
Your point about trusting conventional code is well made and important. Once I repeated that I shouldn't roll my own crypto. A cryptographer shrugged and told me, I mean, somebody has to write it, and that person might be you. (That person isn't me. I don't roll my own crypto. I do roll my own auth, because I'm comfortable with my understanding of authn/authz attacks. Use my software at your peril.)
Regarding complexity what I was thinking is that, after a lot of clever reflection, you might realize the proper solution is actually to take something away. To give an illustrative though not very realistic example, you might realize you didn't actually need a web backend at all and that the app can function local-only. Thereby solving your UX and security issues - client side validation is now completely acceptable. This architecture is simpler (less complex) in that the diagram contains fewer elements, but more sophisticated in that it contains more baked-in wisdom about how your normally web-based application can fulfill all it's requirements locally.
>To give an illustrative though not very realistic example, you might realize you didn't actually need a web backend at all and that the app can function local-only.
ssshhhh, don't give away the only secret that keeps us employed.
if they knew for certain our stuff wouldn't break, we wouldn't had been kept around.
Ultimately the risk transformation is exponential; don't roll your own crypto, don't DIY authentication/authorization, don't risk your own inconvenience and assume security.
However the opposite, to use all the "agreed"-upon code, introduces a near similar surface area of risk, simply spread across more vectors. And because the vectors are spread, and the system is more complex, the dissolution of responsibility leads to the opportune laziest option - patching code together, trusting it works.
it would be wise to question why this convention is so normalized.