4 ms·

You seem to be missing the point of the article: producing less bugs and better code can be wrong if writing that code slows down finding out what the problem i

by davi 17y ago

You seem to be missing the point of the article: producing less bugs and better code can be wrong if writing that code slows down finding out what the problem is. Speed-of-writing-good-code is an orthogonal parameter, here.

shin_lao 17y ago
This is where I disagree. Trying to be industrial strength for a proof of concept or an experiment is typically a junior's mistake.
- cema 17y ago
  I agree this mistake is typical, but I would not be surprised to see a senior make it. A related mistake is, of course, to keep a pilot project in production (usually as the core of the production project, with a variety of both functional and structural additions to keep it sort of working). This mistake is usually a result of a management decision more than development (but could be the same person).
- absconditus 17y ago
  Believing that your proof of concept or prototype won't end up in production is another junior's mistake.
jerf 17y ago
No, it's not orthogonal. I can see it in things like the complaints about how foreign keys "caused problems" in the migrations. Generally, that means one of two things: The foreign keys were actually preventing bugs in your migrations (which even in a startup context is a Good Thing(TM), as "buggy migration" is effectively slower than "correct migration" no matter how fast the buggy migration is), or the developer was not experienced enough with foreign-keyed databases to really know how to migrate this. Bear in mind that if you screw up hard enough there's no guarantee you can recover. Anybody hanging around this site for long enough has read at least a couple of stories about the technical error that brought the whole startup down because there weren't enough resources to recover, and "botched database upgrade" (combined with "failure to backup", which of course occurred because there was no time, we're going too fast and we're too awesome!!! to do the backup) is a prime candidate for that sort of event. I say the latter because I've been there. Setting up foreign keys is one skill. Learning how to migrate them is another. I've screwed it up before. It does take a bit of learning. But once you learn it, you're still better off using them properly in the first place. There's also some skill in learning how to set up your database so it can be migrated; I'm not even sure how to begin putting it into words, but there's definitely some skill involved there. (I'm not guaranteeing I've got it all figured out, but I've certainly improved, which is enough to establish that it is a skill.) They're not equivalent either, certainly, but when you say "orthogonal", you're making the claim that they are not just different (which is true), but utterly unrelated, and that claim is unsupportable. I've been deliberately spending my last couple of years learning how to build things both fast and right, and I've gotten to the point where I can spank anybody just "hacking around" after about a two-month window, after which it's all profit. In fact I'm building a system replacing just such an effort right now... well, after I stop posting this anyhow. My system isn't a glorious paragon either because as an experienced developer I know where to cut corners to get it out, but it's a lot stronger than the hack job it's replacing (and I'm doing it in less time, too). (Part of the reason I started this learning is that I was at a startup where I did in fact make this exact error. In the end, this is not what killed it (what killed it was the management insisting that there was always just one more feature we needed before release, and then once we had that, there was just one more, repeat until out of money with no customers), but I've made this mistake and I won't make it again. But the alternative is not hackhackhackhackhack, the alternative is being more familiar with the cost/benefits ratios and picking the winners, some of which will still be "do it right", and some will not. Hardcoding the answer in either direction is wrong, as it pretty much always is.)
- zackattack 17y ago
  what does orthogonal mean in this context
  - jerf 17y ago
    Two vectors are orthogonal if the addition of one of them does not affect the "amount" of the other, when using them as basis vectors. In this case, "(1,0)" and "(0,1)" are orthogonal; no matter how far in X you go, the amount of Y-ness doesn't change. (1,1) and (1,-1) are also orthogonal. In the metrics most people learn, this means the vectors are at right angles. (Forgive me this simplification, mathematicians, going further will only obscure things.) Programmers tend to abuse this term to mean "the two things are totally unrelated", even though the term really only applies to certain mathematical constructs like vectors. Claiming that type-safety is orthogonal to garbage collection would mean the two are entirely separate concerns and that you can freely have none, one, or both, and that the two issues never matter to each other. Now, technically this isn't quite true, which is why I say we "abuse" the term, because the full meaning of "orthogonal" is that you will literally never be considering the effect of one while examining the other, and this is not true; type systems do some impact on GC, for instance. However, in many cases this is "true enough" for someone to say they are "orthogonal". In this case, I'm not arguing merely that the precise definition is not met, because it pretty much never is, but that the spirit in which programmers use the term is also not applicable here, as the questions of "code quality", "speed", and "developer experience" are indeed tightly interrelated and so answers like "you always have to sacrifice quality for speed" are too simplified.
  - btilly 17y ago
    In simple English, orthogonal means "at right angles". People often say that two things are orthogonal when they mean is that they are different dimensions that are unconnected with each other. To pick a silly example, the number of coffee cups I have is orthogonal to the number of jars of jelly beans I have.
- davi 17y ago
  Let's see if you agree with this restatement of your post: Fast, mediocre coders may be able to iterate really fast in order to get something out in front of users. This means that when you don't know what the problem or the solution is (as discussed in the article), they can be effective at identifying the problem that requires the solution. But if their crummy code gets used as the nucleus of the solution (once the problem has been identified), the startup can often ensure its own doom. This means that in successful startups, speed-of-writing-good-code and speed-of-problem-identification are strongly correlated, and therefore cannot be called orthogonal. I agree with this & think it's a useful refinement to my thinking. Thanks.
moron4hire 17y ago
Why is writing good code slower than writing bad code? I'd rather write good code once, now, rather than bad code now and good code later.
- dstorrs 17y ago
  According to my definitions, good code must perform correctly or else fail gracefully. It must also be robust, debuggable, and maintainable. Those extra conditions mean thinking more, and writing more code. That takes extra time over hacking out the quick-and-dirty version. For example, right now I'm helping a friend out with a project to send email. In about 10 minutes I could whip something out that does this using backticks (i.e., shell escapes), no error checking, no logging, etc. It would be in front of the customer and suitable for feedback very quickly. It would also be short, easy to understand, and would do its job correctly 99% of the time. All of these are good things, but it would still be bad code, because the other 1% of the time it's going to break horribly and someone is going to have to come in and fix it.

by davi 17y ago

shin_lao 17y ago

This is where I disagree. Trying to be industrial strength for a proof of concept or an experiment is typically a junior's mistake.

cema 17y ago
I agree this mistake is typical, but I would not be surprised to see a senior make it. A related mistake is, of course, to keep a pilot project in production (usually as the core of the production project, with a variety of both functional and structural additions to keep it sort of working). This mistake is usually a result of a management decision more than development (but could be the same person).
absconditus 17y ago
Believing that your proof of concept or prototype won't end up in production is another junior's mistake.

jerf 17y ago

No, it's not orthogonal. I can see it in things like the complaints about how foreign keys "caused problems" in the migrations. Generally, that means one of two things: The foreign keys were actually preventing bugs in your migrations (which even in a startup context is a Good Thing(TM), as "buggy migration" is effectively slower than "correct migration" no matter how fast the buggy migration is), or the developer was not experienced enough with foreign-keyed databases to really know how to migrate this. Bear in mind that if you screw up hard enough there's no guarantee you can recover. Anybody hanging around this site for long enough has read at least a couple of stories about the technical error that brought the whole startup down because there weren't enough resources to recover, and "botched database upgrade" (combined with "failure to backup", which of course occurred because there was no time, we're going too fast and we're too awesome!!! to do the backup) is a prime candidate for that sort of event. I say the latter because I've been there. Setting up foreign keys is one skill. Learning how to migrate them is another. I've screwed it up before. It does take a bit of learning. But once you learn it, you're still better off using them properly in the first place. There's also some skill in learning how to set up your database so it can be migrated; I'm not even sure how to begin putting it into words, but there's definitely some skill involved there. (I'm not guaranteeing I've got it all figured out, but I've certainly improved, which is enough to establish that it is a skill.) They're not equivalent either, certainly, but when you say "orthogonal", you're making the claim that they are not just different (which is true), but utterly unrelated, and that claim is unsupportable. I've been deliberately spending my last couple of years learning how to build things both fast and right, and I've gotten to the point where I can spank anybody just "hacking around" after about a two-month window, after which it's all profit. In fact I'm building a system replacing just such an effort right now... well, after I stop posting this anyhow. My system isn't a glorious paragon either because as an experienced developer I know where to cut corners to get it out, but it's a lot stronger than the hack job it's replacing (and I'm doing it in less time, too). (Part of the reason I started this learning is that I was at a startup where I did in fact make this exact error. In the end, this is not what killed it (what killed it was the management insisting that there was always just one more feature we needed before release, and then once we had that, there was just one more, repeat until out of money with no customers), but I've made this mistake and I won't make it again. But the alternative is not hackhackhackhackhack, the alternative is being more familiar with the cost/benefits ratios and picking the winners, some of which will still be "do it right", and some will not. Hardcoding the answer in either direction is wrong, as it pretty much always is.)

zackattack 17y ago
what does orthogonal mean in this context
- jerf 17y ago
  Two vectors are orthogonal if the addition of one of them does not affect the "amount" of the other, when using them as basis vectors. In this case, "(1,0)" and "(0,1)" are orthogonal; no matter how far in X you go, the amount of Y-ness doesn't change. (1,1) and (1,-1) are also orthogonal. In the metrics most people learn, this means the vectors are at right angles. (Forgive me this simplification, mathematicians, going further will only obscure things.) Programmers tend to abuse this term to mean "the two things are totally unrelated", even though the term really only applies to certain mathematical constructs like vectors. Claiming that type-safety is orthogonal to garbage collection would mean the two are entirely separate concerns and that you can freely have none, one, or both, and that the two issues never matter to each other. Now, technically this isn't quite true, which is why I say we "abuse" the term, because the full meaning of "orthogonal" is that you will literally never be considering the effect of one while examining the other, and this is not true; type systems do some impact on GC, for instance. However, in many cases this is "true enough" for someone to say they are "orthogonal". In this case, I'm not arguing merely that the precise definition is not met, because it pretty much never is, but that the spirit in which programmers use the term is also not applicable here, as the questions of "code quality", "speed", and "developer experience" are indeed tightly interrelated and so answers like "you always have to sacrifice quality for speed" are too simplified.
- btilly 17y ago
  In simple English, orthogonal means "at right angles". People often say that two things are orthogonal when they mean is that they are different dimensions that are unconnected with each other. To pick a silly example, the number of coffee cups I have is orthogonal to the number of jars of jelly beans I have.
davi 17y ago
Let's see if you agree with this restatement of your post: Fast, mediocre coders may be able to iterate really fast in order to get something out in front of users. This means that when you don't know what the problem or the solution is (as discussed in the article), they can be effective at identifying the problem that requires the solution. But if their crummy code gets used as the nucleus of the solution (once the problem has been identified), the startup can often ensure its own doom. This means that in successful startups, speed-of-writing-good-code and speed-of-problem-identification are strongly correlated, and therefore cannot be called orthogonal. I agree with this & think it's a useful refinement to my thinking. Thanks.

moron4hire 17y ago

Why is writing good code slower than writing bad code? I'd rather write good code once, now, rather than bad code now and good code later.

dstorrs 17y ago
According to my definitions, good code must perform correctly or else fail gracefully. It must also be robust, debuggable, and maintainable. Those extra conditions mean thinking more, and writing more code. That takes extra time over hacking out the quick-and-dirty version. For example, right now I'm helping a friend out with a project to send email. In about 10 minutes I could whip something out that does this using backticks (i.e., shell escapes), no error checking, no logging, etc. It would be in front of the customer and suitable for feedback very quickly. It would also be short, easy to understand, and would do its job correctly 99% of the time. All of these are good things, but it would still be bad code, because the other 1% of the time it's going to break horribly and someone is going to have to come in and fix it.