Products > Security

UK NATS Outage - August 2023 - Report

<< < (3/3)

SiliconWizard:

--- Quote from: AndyBeez on September 11, 2023, 11:21:22 pm ---
--- Quote from: tggzzz on September 11, 2023, 09:44:36 pm ---Old adage, which I'm sure you are aware of: "you can't test quality into a product".
Software weeklies believing the TDD dogma can't understand that.

--- End quote ---
One issue with TDD (test driven development) is code, and exception catching, is built to only pass the test cases.

--- End quote ---

Yes, it is one pitfall, which is a consequence of a method that focuses on one particular aspect of things - so just like with other methods that revolve around one principle only, teams will just naturally tend to focus on this one aspect.

The main root problem, beyond being too obsessively focused on tests, is that it assumes it's actually possible to design tests that fully cover requirements, and that while doing so, people are less likely to introduce errors than when implementing functionalities themselves. That's just not so, and it's flawed.

One merit I see with this approach is if tests are designed by people different from those who implement. Not because tests are per se all that meaningful, but mostly because that's now two related parts of the design that are confronted to one another, and that's always good. Note that you'd get the same benefit, potentially with more insights, by making two different people/teams implement the same feature, and compare the 'outputs' of the two implementations vs. a common set of 'inputs'.

And then, beyond the flaw of assuming that tests will adhere to the specs more closely than the implementation, there's the major problem of the specs themselves - against which you design said tests.
In a large majority of software defects, the root cause is with faulty specs, or even the absence thereof. No amount of TDD is going to help with that.

Marco:

--- Quote from: tridac on September 10, 2023, 06:09:54 pm ---all input data is validated before being accepted by the system.
--- End quote ---
Wouldn't really help in the case as described, it was ostensibly valid, but an unexpected cornercase.

Assuming each flight can be handled seperately I'd fork, limit the amount of memory the process could use and never route more than fit in memory at the same time worst case. Segfault, OOM, time out, error, garbage output ... flight goes on the failed heap and you move on. Always assume your code is garbage. It's so little data from a modern computer standard just doing process isolation makes most sense if possible.

I still can't imagine they don't have a codepath for failed routing already other than panic and stop everything.

Navigation

[0] Message Index

[*] Previous page