Hacker News new | ask | show | jobs
by catnaroek 3712 days ago
Writing correct software isn't just a matter of having the right tools and processes, even if those can help. It's primarily a know-how issue. No amount of process can fix using the wrong algorithms or coming up with the wrong designs.
2 comments
lmm 3712 days ago
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.
link
sievebrain 3712 days ago
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.

link
lmm 3712 days ago
> 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.

link
catnaroek 3712 days ago
> 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.

link
catnaroek 3712 days ago
> 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?

link
lmm 3712 days ago
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.
link
srtjstjsj 3710 days ago
wrong algorithms and wrong designs are not the cause of bugs and catastrophic failures. Simple unit mis-conversions and boundary cases are.
link