23,327 reputation
14893
bio website back2dos.wordpress.com
location LE City - Germany
age 29
visits member for 4 years, 4 months
seen 13 hours ago

"the code is the design"


15h
comment Leaving intentional bugs in code for testers to find
@Dunk You are simply contradicting yourself. You said the number you proposed is a sensible metric. It is far from it, as I have abundantly explained. Your analogy is much better suited for your claim than mine. Why I say the idea is not terrible is because it is merely the application of the general idea that if somebody improves during training, they will do better in the field. That's why people train. Of course you cannot accurately measure the effectiveness of QA. I didn't claim you can. But suggesting to therefore not even try is a perfect solution fallacy.
15h
comment Leaving intentional bugs in code for testers to find
@Dunk No that is not "completely and totally false". Try reasoning in categories other than extremes. I said the number correlates more than the one you proposed. If less bugs make it into production in release B than in release A, then it can meaning anything. For example that release B was easier to get right. Or, as I said, that the programming methodology has improved or what not. Or that users do not discover the features in B and therefore do not report defects they encounter. Almost none of the effects you propose measuring say anything about the QA.
1d
comment Leaving intentional bugs in code for testers to find
@Dunk As opposed to that, the "false error" actually does give you more information, under the assumption that the difficulty of finding them doesn't fluctuate erratically (which can be arranged). Because you know how many artificial defects there are, you can tell exactly what percentage of them were caught in QA. So the extra information you get is how effective QA is in detecting artificial defects. And that number certainly correlates more with their overall effectiveness than the one you suggested.
1d
comment Leaving intentional bugs in code for testers to find
@Dunk Then you didn't read the question properly. It suggests that this method increases morale and also thoroughness. Also the number of bugs that make it through QA doesn't reliably measure the effectiveness of the QA team. It is equally affected by how many bugs the developers introduce. If they start using TDD and there is a sudden decrease in defects in the release, what does that say about the testers? Nothing.
1d
comment Leaving intentional bugs in code for testers to find
@Dunk: Keeping track of that number won't make your team better automatically, much like keeping score in a sport doesn't make you the best athlete you could be. In fact athletes do train, i.e. perform artificial tasks to increase their performance in a controllable fashion, which is not unlike what is being proposed here. Unless you have an idea how to get people to improve that number, it's of little value.
1d
answered Leaving intentional bugs in code for testers to find
1d
answered How to politely decline a pull request?
Jan
13
comment Is “White-Board-Coding” inappropriate during interviews?
@JuliaHayward: If you give every applicant the same problem, then of course the response becomes google-able. Not surprising, is it? But again, my answer remains: do not do whiteboard coding on fizzbuzz level in an interview. It just shows that you didn't bother preparing a good and interesting problem. As you have said yourself, there are ways to establish basic programming abilities way before you invite the candidates to your whiteboard.
Jan
13
comment Is “White-Board-Coding” inappropriate during interviews?
@JuliaHayward: Establishing a candidate's basic coding abilities in a pre-interview is a different thing. You don't actually have to invite somebody on site to do that. You can send them a small problem that they can solve. Possibly discuss that solution (or github code) in person. Most imporantly: It's highly unlikely you will find a candidate able to gracefully master the type of problem I suggest, while not being able to solve fizzbuzz type problems. The interview should be used to determine how able the candidate is to deal with the complexity typical of real world problems.
Jan
12
comment Stack and Heap memory in Java
@hagubear: It depends. In some cases the JIT (or even the compiler) is able to avoid allocation (and the overhead it incurs). But unlike in C for example, you are not actually explicitly saying where the value should be allocated.
Jan
8
awarded  Nice Answer
Jan
7
comment Does using == in JavaScript ever make sense?
@EricKing: I disagree. It's not that I like JavaScript. I much prefer to use statically typed languages, where static analysis forces you to ensure the operands have sensible types. But if you make it a design philosophy that your language should be forgiving by automatically coercing things at runtime as needed, you can't do it everywhere except with the == operator. The result is would be unusable. Given certain axiomatic design decision, this is sensible behavior. Dismissing that seems like a perfect solution fallacy.
Jan
7
comment Does using == in JavaScript ever make sense?
@EldritchConundrum: Again: relationship operators are meant to compare numerical values, where one operand may in fact be a string. For operand types for which >= is meaningful, == is equally meaningful - that's all. Nobody says you should compare [[]] with false. In languages like C the result of this level of nonsense is undefined behavior. Just treat it the same way: don't do it. And you'll be fine. You also won't be needing to remember any magic rules. And then it's actually rather straight forward.
Jan
7
comment Does using == in JavaScript ever make sense?
@EldritchConundrum: As I have tried to explain, the behavior of >= is rather consistent with the rest of the language/standard APIs. In its totality, JavaScript manages to be more than the sum of it's quirky parts. If you'd like a >==, would you also want a strict +? In practice, many of these decisions make many things a lot easier. So I wouldn't rush to judging them as poor.
Jan
6
comment Does using == in JavaScript ever make sense?
@BenjaminGruenbaum: That's like saying + is not really commutative, because NaN + 5 == NaN + 5 doesn't hold. The point is that >= works with number-ish values for which == works consistently. It shouldn't be surprising that "not a number" is by its very nature not number-ish ;)
Jan
6
answered Does using == in JavaScript ever make sense?
Jan
4
comment Do ALL your variables need to be declared private?
@supercat: For somebody who has a point to make, you are writing an awful lot. You haven't yet said anything that is relevant to my criticism to this answer. Or to the question. This question was asked in a C# context, where setters are syntactically transparent. Your semantic comparison is a false dichotomy. You are confounding collections and tuples. You open a side topic on atomicity, which you get for free with immutability, which really only undermines my stance. And so on and so forth. Please stick to this answer and my remarks to it. Because this is going nowhere.
Jan
2
comment What would be good factual arguments to convince high level management to consider functional programming?
If you are going for an all-or-nothing move to FP, management will definitely reject. Even your peers will. FP and OOP are orthogonal and you should try to use tools that allow you to choose the right paradigm as needed. Find a smooth way to transition into FP. If you are really good at it, you can start by adding functional code to your code base, giving you tangible results that will speak for themselves. If not, get good at it first.
Jan
2
comment Do ALL your variables need to be declared private?
@supercat: Blanket statements about efficiency are weak arguments. If there is a hard performance requirement, that can demonstrably be met only by adding mutability, then ok. FYI, a modern JIT will be able to stack allocate tuples where it matters. Immutability only makes this kind of optimization easier. Still, my original point is that the example code is very poor to start with. You are not contradicting that. You are also not giving any reason why the mutable records you speak of shouldn't have accessors rather than public fields. Most importantly: we're going quite a bit off topic ;)
Dec
31
comment Do ALL your variables need to be declared private?
@supercat: Tuples (which I think is a more common name for what you speak of) are immutable, which makes guarantees about the integrity of a tuple invariant, thus actually giving the code that creates the compound value the means to statically enforce the responsibility you speak of. The same cannot be said for an object with a bunch of public fields. Notice how even .NET tuples are actually defined with readonly properties for just that reason. So: the use case you are describing has nothing to do with this answer and it actually drives home the point contended in the question.