[lmm]

Suboptimal algorithms may lead to poor performance but you can enforce correctness. If you let the requirements drive the design rather than trying to design up-front (i.e. good process) you end up with good design. Asking the right questions to gather the correct requirements is arguably in-score or not, but again it's primarily a process issue.

[sievebrain]

You can't always enforce correctness. Consider the case of a typical web dev shop that hires a developer who thinks escaping is a good solution to SQL injection. It might get snuck past code review if you're unlucky.

There are static analysis tools that can identify such problems ... sometimes ... maybe ... depending on the language and frameworks in use. But to deploy such tools you have to know about them to begin with. And most devs can't simply produce such a tool if there isn't one on the market because that's not what they're being paid to do.

Unfortunately, knowhow can't be automated away entirely just yet.

[lmm]

> Consider the case of a typical web dev shop that hires a developer who thinks escaping is a good solution to SQL injection. It might get snuck past code review if you're unlucky. > There are static analysis tools that can identify such problems ... sometimes ... maybe ... depending on the language and frameworks in use.

Analysis tools are the wrong approach - that code should be simply impossible if you're typing things correctly, and inadequately typed code should be very obvious in code review.

> And most devs can't simply produce such a tool if there isn't one on the market because that's not what they're being paid to do.

Most devs could write such a thing if the company told them to. The reason "that's not what they're being paid to do" comes down to process.

[catnaroek]

> Most devs could write such a thing if the company told them to. The reason "that's not what they're being paid to do" comes down to process.

Most organizations barely have enough of a budget to implement the applications they actually need using already existing infrastructure (frameworks, tools, etc.). Asking these organizations to roll their own infrastructure is like asking ordinary people to run their own water or power utility.

[catnaroek]

> If you let the requirements drive the design rather than trying to design up-front

I don't understand this dichotomy. What kind of engineer designs anything for a third party without gathering their requirements?

[lmm]

I meant more that you need to let the things you encounter during implementation drive the design. This is particularly relevant when requirements change (as they often do), but even if you can nail down the spec perfectly up-front, trying to design at that stage is still a mistake.