41–50 of 77 posts
Earlier quoted context omitted.
Arguing from the point of logic and formalisms the author is talking about, this would seem to be true.
> Instead, it reduces that number to c' * N with c' That is unproven conjecture. It feels right, but just because it is written as a formula doesn't automatically mean it is correct.
If your testing is such that this isn't true then you are doing testing wrong, in a self-evident sort of way.
> Bugs are correlated with lines of code and TDD forces writing more code so how can it reduce bug counts? If the test code has no bugs then just write the rest of the code in the same style Nobody has pointed out the fault in this reasoning yet, so I will. The linear relationship lines-of-code vs. total-bug-count is based on independence of bug introduction in different parts of the code. That is, introducing a bug…
>So here’s the punchline: if you want to be a good programmer then learn a technology and language agnostic formalism. Logic, statistics, and game theory are probably good bets. I think in an abstract sense control theory is a reasonably good bet. https://en.wikipedia.org/wiki/Control_theory I can't say I know it deeply, but a lot of the ideas resonate when I think about software engineering. If you think of everythi…
good recommendation, if the author understood control theory he'd understand that code that feedbacks on code is quite different than code with no feedback loop. while I find it hard to find anything I'd recommend about the authors article as most of the reasoning seems a little off, I can understand the sentiment of the article . Agile and TDD are really recognition of control theories ideas of feedback loops keep t…
This in my experience is the most important factor.
Earlier quoted context omitted.
You don't know that the test code is free of bugs. You don't need to. Case 0: No bugs in the test code. All is well. Case 1: Bug in the test code that causes some bugs in the real code not to get caught. That's bad, but you're no worse off than if you didn't have the test at all. Case 2: Bug in the test code that causes correct real code to look buggy. Result: the test fails, you look for problems, most likely you fi…
I see 5 cases: Code | Test | Result -------------------------------------------------- fine | fine | a) We have a regression test, yay! fine | buggy | b) Someone breaks the code to make the test work. Oops. c) Someone fixes the test, we have a regression test, yay! buggy | fine | d) We'll fix the code, and we have a regression test, yay! buggy | buggy | e) Bug remains in code. Oops. If the probability of introducing…
Earlier quoted context omitted.
Tests don't exist for solving bugs as much as they exist to prevent regression. Writing exhaustive tests is not sufficient to bring c' to zero, because some of those bugs exist because of the developer's own presumptions about how code should behave.
But testing exhaustively means the full range of inputs are used, and therefore, if a bug arises as inputs not considered by the dev initially, it would show up as a failure. What you're actually saying is that reaching full exhaustive testing is near impossible.
If I understood func(5, 6) should return 9, but the client actually wants 10, no amount of tests I write will reveal the error.
However I agree with the article's general idea. In the aviation industry there already are languages abstracting computers' internals and allowing programmers to reason about safety-critical programs using more high level constructs.
Due to its nature, I think there won't be such a technology for general purpose languages -- in order to be general enough, you can't have too much things abstracted away. Maybe we couldn't go much farther than what languages like Basic allows us.
On the other hand, I wish we had such languages for more specific tasks like ERP-like software, business web applications and so on. It's worth noticing that many of the biggest ERP companies in the world have their proprietary domain specific languages.
[0] https://www.microsoft.com/en-us/research/blog/exploding-soft...
Earlier quoted context omitted.
Out of curiosity, which more modern stacks were those?
Most NodeJS with ReactJS frontends. Some of them had already started doing React for frontend and just need the backend work.
Earlier quoted context omitted.
But testing exhaustively means the full range of inputs are used, and therefore, if a bug arises as inputs not considered by the dev initially, it would show up as a failure. What you're actually saying is that reaching full exhaustive testing is near impossible.
I think what they're saying is that both the code and test will contain the bug, since the bug is in the programmer's understanding rather than just in their coding. If I understood func(5, 6) should return 9, but the client actually wants 10, no amount of tests I write will reveal the error.
> Bugs are correlated with lines of code and TDD forces writing more code so how can it reduce bug counts? If the test code has no bugs then just write the rest of the code in the same style Nobody has pointed out the fault in this reasoning yet, so I will. The linear relationship lines-of-code vs. total-bug-count is based on independence of bug introduction in different parts of the code. That is, introducing a bug…
The other fault in that reasoning is that usually test code is much much simpler than product code. It's a lot harder to write bugs when the structure of the code is just 1. call single function with some input data 2. verify that output data/side effects meet expectations 3. repeat for more sets of inputs.
Earlier quoted context omitted.
Arguing from the point of logic and formalisms the author is talking about, this would seem to be true.
> Instead, it reduces that number to c' * N with c' That is unproven conjecture. It feels right, but just because it is written as a formula doesn't automatically mean it is correct.
If adding test code makes your code under test more bug-prone, something has gone horribly, terribly wrong.