5 ms·

You're making an implicit assumption in this comment; that Facebook is in an optimal position and every decision they made contributed to that optimal position

by ebbv 10y ago

You're making an implicit assumption in this comment; that Facebook is in an optimal position and every decision they made contributed to that optimal position in a positive way and so any change is for the worse. But what if they aren't in an optimal position? What if having a higher quality code base all along would have let them dominate social media more and faster, and perhaps be more successful in areas they have stumbled in the past? A lot of people (especially non-technical folks and inexperienced coders) seem to think that code quality comes at a cost and that a bad code base full of technical debt is just a side effect of fast iteration and the cost of being quick to market. I say that's crap. A higher quality codebase with less technical debt actually improves speed tremendously because it lets you iterate faster with fewer rewrites down the road and it will be more stable and result in fewer distractions from having to put out fires with unforeseen bugs making it into production. A sloppy codebase with technical debt is much more costly on your ability to go to market and add features and iterate.

emodendroket 10y ago
> But what if they aren't in an optimal position? What if having a higher quality code base all along would have let them dominate social media more and faster, and perhaps be more successful in areas they have stumbled in the past? Well, I don't know. What if spending so much time on quality would have led to it never catching on? 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.
- 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 ago
      You're just reaffirming the fallacy. You don't save time by skimping on quality, it's foolish to think otherwise.
      - emodendroket 10y ago
        Well, 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 ago
        I 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 ago
    I'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.

by ebbv 10y ago

emodendroket 10y ago

> But what if they aren't in an optimal position? What if having a higher quality code base all along would have let them dominate social media more and faster, and perhaps be more successful in areas they have stumbled in the past? Well, I don't know. What if spending so much time on quality would have led to it never catching on? 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.

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 ago
    You're just reaffirming the fallacy. You don't save time by skimping on quality, it's foolish to think otherwise.
    - emodendroket 10y ago
      Well, 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 ago
      I 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 ago
  I'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.