3 ms·
> What if spending so much time on quality Your reply includes the very fallacy that I mention in my comment that you're replying to. Namely that better qualit
by ebbv 10y ago
> What if spending so much time on quality
Your reply includes the very fallacy that I mention in my comment that you're replying to. Namely that better quality code requires more time. Again, I say, that's not really the case. If you write better code you will spend less time debugging, adding features and iterating in the future, and I would argue it takes less time to write better code once you're in the habit of it.
But of course any number of things are possible, they could have written better code and failed. They could have written even worse code than they did and failed. Who knows. My point wasn't "Facebook should have written better code and then Zuckerberg would have another $10 billion." My point was that the comment I was replying to was based on some assumptions that, for me, aren't true.
> It is curious that the world is full of compromises like Unix, QWERTY, C, VHS, etc., all of which had arguably superior competitors that failed to catch on.
But it's the arguably superior that matters here. For each of them there are circumstantial reasons why they beat out competitors, and it's usually not really because of the mythical "worse wins" baloney. In reality there's usually a number of reasons that combine together for a given result, and that's certainly the case with, for example, VHS vs. Beta. Costs of tapes and players, Sony's tight control of Beta, camcorders, etc. all combine together.
Anyway, we're way off on a tangent now. My point was it's a fallacy that writing worse code is a short cut. It's like driving badly vs. driving well. You're still going to the same place on the same roads.
- emodendroket 10y ago> If you write better code you will spend less time debugging, adding features and iterating in the future, and I would argue it takes less time to write better code once you're in the habit of it. Yes, that's probably true. But you'll spend more time now. Sometimes that might be time you don't have.
- carapace 10y agoYou're just reaffirming the fallacy. You don't save time by skimping on quality, it's foolish to think otherwise.
- emodendroket 10y agoWell, no, I don't agree. There are lots of opportunities to say "this really ought to be refactored... but whatever, it more or less works" when working on a typical application.
- collyw 10y agoI was asked for an estimate for a project I was working on. I said ~65 days. Now the deadline will give me around 40 days of work on it. I'll need to cut corners to make that, but I know in the end it won't be a finished product that we will be releasing and it will cost more time in the long run as I'll need to go back and redo parts of it. But we have a deadline now so I'll need to cut corners. The obvious way to do that is to focus on the most used parts of the application being done well, and finish / refactor the less used parts later.
- dasil003 10y agoI'm with you that deliberately writing shitty code does not really save time. The technical debt from cut corners comes back to bite you surprisingly quickly. However, given a minimum bar of quality, where I've seen the biggest quality issues crop up are due to the layering of code over time written by different developers with views of the problem domain and different priorities. Solving these kinds of issues often requires major time investment in refactoring to align the new worldview with the old. Doing so successfully requires a clear vision that is harder and harder to coalesce as the code base gets more complex. Good architecture mitigates, but is only possible to the extent that the fundamental business logic allows. Deciding when to refactor and realign older code and architecture is where the hard decisions are, not so much in today's coding choices.