3 ms·

Not sure I understand your point, care to elaborate?

• ArkyBeagle 10y ago
  I think getting the price down on better solutions takes some measure of innovation and thinking. It may be test harnesses. It may be extensive prototyping. It often involves investing in equipment. From the coding perspective, it involves having structure be transparent to function. Everything is explicit; have requirements be represented such that they're almost derivable from the code base without testing. This doesn't mean you don't test; it means you do both. The your concern is the consistency of the written requirements, the code base and the results of tests. As an example, I worked on a thing that would cost tens of thousands for one field test. For about a half or a fourth of the cost of that, I was able to mock a field test in the engineer's desktop - not in a lab, but right there. This required a small amount of equipment, about two-four cubic feet worth. This was based on extensive sets of logged data, translated into models. Of course it's by definition inadequate; there are lies, damn lies and simulations. But being able to anneal defects back through the models means you lose a lot less information. I eventually put a thing together in a VM that mocked the entire system. I actually did feature-adds against that, that worked just fine. I was (briefly) able to show about a factor of ten improvement in defect rate. But nobody on the team wanted to own this. the implicit message was "we do the thing; not that thing you just did." It's now a failing organization, so I'm sure all that got dumpstered. That's fine; I lit a candle instead of cursing the darkness.