3 ms·

No mention of the obvious answer here; because coders have jobs, employers and lives. Hence a lot of the time, code has to be written quickly and the company u

by CM30 11y ago

No mention of the obvious answer here; because coders have jobs, employers and lives. Hence a lot of the time, code has to be written quickly and the company usually doesn't give a toss whether something's been done the 'right' way... so long as it works. If you've got a deadline in thirty minutes, you're probably not going to try and do everything the best possible way. Same deal if you've got a family or friends to get back to, an event to go or anything else that requires you to get things done quickly. You're rewarded more for getting things done quickly than you are getting them done properly or securely. When your client wants their site or program done as quickly as possible for a low cost, or your startup needs to 'move fast and break things'... security will usually suffer in the process.

jacquesm 11y ago
> so long as it works. That's what I call the 'happy path fallacy'. If code performs along the happy path, then great, move fast, break things and release. Never mind that outside the happy path there are tons of issues, bugs, things never even looked at until they suddenly are found to be the root cause of a major breach. Those parts do not get the attention they need because there is no direct economic incentive to do so. Software is not at all done when it 'works'. It's only done when it works well for all input and there are no unknown paths of execution that lead to unexpected results. It's pretty rare for a codebase with more than a few 100 lines to be completely known to such a level that there isn't a way to cause it to do something the author did not intend to be there. Complexity is a very bad enemy in that respect and code tends to get extremely complex and hard to reason about if you don't have iron discipline during the design process.
TheAndruu 11y ago
To add to this, coders frequently have managers who don't allow time to test and improve much beyond what works, even when asked for.
- collyw 11y ago
  Exactly! It is often that the coders are the ones pushing to do thing more correctly, but mnagemnt wants the latest feature out.
  - TheAndruu 11y ago
    I've been multiple places where requests to fix what was broken in the production system were shot down repeatedly because there "wasn't money in the budget to fix that system". Yet if anyone added up the manhours it took to fix the same production issues that repeatedly popped up, it would've clearly been less expensive to fix the recurring bugs.
ternaryoperator 11y ago
That's precisely it. And it's been the same reason for the last few decades. The level of security in software won't change significantly until the cost of writing insecure software exceed the costs of writing secure software.
sln 11y ago
You missed the whole point of this essay. The fastest code to write is often insecure because languages, apis and so on are almost always insecure-by-default. If you write code fast because you have a life at home to get to, and I write code fast because my employer needs it right now, and someone else writes code fast because they have a large ego to maintain, what really is the difference? If the simplest thing to do is also reasonably secure then the hope is a 30 minute deadline will not lead to an accidental security flaw.

by CM30 11y ago

jacquesm 11y ago

> so long as it works. That's what I call the 'happy path fallacy'. If code performs along the happy path, then great, move fast, break things and release. Never mind that outside the happy path there are tons of issues, bugs, things never even looked at until they suddenly are found to be the root cause of a major breach. Those parts do not get the attention they need because there is no direct economic incentive to do so. Software is not at all done when it 'works'. It's only done when it works well for all input and there are no unknown paths of execution that lead to unexpected results. It's pretty rare for a codebase with more than a few 100 lines to be completely known to such a level that there isn't a way to cause it to do something the author did not intend to be there. Complexity is a very bad enemy in that respect and code tends to get extremely complex and hard to reason about if you don't have iron discipline during the design process.

TheAndruu 11y ago

To add to this, coders frequently have managers who don't allow time to test and improve much beyond what works, even when asked for.

collyw 11y ago
Exactly! It is often that the coders are the ones pushing to do thing more correctly, but mnagemnt wants the latest feature out.
- TheAndruu 11y ago
  I've been multiple places where requests to fix what was broken in the production system were shot down repeatedly because there "wasn't money in the budget to fix that system". Yet if anyone added up the manhours it took to fix the same production issues that repeatedly popped up, it would've clearly been less expensive to fix the recurring bugs.

ternaryoperator 11y ago

That's precisely it. And it's been the same reason for the last few decades. The level of security in software won't change significantly until the cost of writing insecure software exceed the costs of writing secure software.

sln 11y ago

You missed the whole point of this essay. The fastest code to write is often insecure because languages, apis and so on are almost always insecure-by-default. If you write code fast because you have a life at home to get to, and I write code fast because my employer needs it right now, and someone else writes code fast because they have a large ego to maintain, what really is the difference? If the simplest thing to do is also reasonably secure then the hope is a 30 minute deadline will not lead to an accidental security flaw.