3 ms·

They will only pay you to fix their code after they've released their product and are selling it for a profit.

jasonlotito 13y ago
Actually, I find that it's usually when the ugly code starts to cost them more. Basically, it's a car without brakes. It will get you where you are going, but it would have cost less all together if you'd installed working breaks from the beginning.
- blowski 13y ago
  To use your analogy, is it better to have a car with no brakes now, or to save up for another year to buy a car with brakes? The problem with the analogy is that it's _obvious_ that you should save up another year because of the danger. But in startup-world, it's not obvious at all. To really abuse your analogy, if you're being chased by wild hungry bears, you don't care whether the car has brakes.
  - jasonlotito 13y ago
    Brakes generally aren't expensive (obviously, this is all relative... but lets ignore that), so instead of waiting a year, your more likely waiting a few days at most. The cost of good quality code isn't expensive either, in the short term or even in the long term. However, for the un-or-misinformed, writing good code might seem higher. Indeed, I'll even go so far as to say that for less skilled individuals, good quality code might seem to increase the cost dramatically. > if you're being chased by wild hungry bears, you don't care whether the car has brakes. A little planning would mean I wouldn't be in that situation: bears and no brakes. Though, it's amusing coming up with ways I could find myself in that position. =)
  - Swizec 13y ago
    The thing with good code is that it's cheaper than bad code. For instance: it takes me 8 minutes to run the full test suite of an app and make reasonably certain nothing is wrong. It takes me 2 hours to get the same assurance manually. And I'll miss most of the problems. Another example: I recently implemented a feature where the feature took ~5 days and fixing the whole codebase to make the feature implementable took 20 days. Had the codebase been using certain libraries correctly without ghetto-coding its own solution, the feature would take me ~5 days.
  - jerf 13y ago
    I don't really like the casual acceptance of the total dichotomy between dirty and clean code here. I'll freely admit you don't always get to clean every bit of code and make it pristine, but on the other hand, with only a small amount of effort and perhaps 5ish years experience it becomes pretty easy to pump out clean-ish code at the same rate you can make an utter, total mess, and recover the value of your slightly higher effort in as little as a week or two, a time frame all but the craziest start ups should still be caring about. Being in a hurry may be license to be "a bit sloppy", but I think it's a mistake to give yourself license to make a total mess, and use your speed as an excuse. For instance, once you're skilled at programming, and assuming you're using a decent language (another thing your startup should be doing), it's at most only slightly slower to refactor something into a function that copy and paste, and that probably still wins on every level the fourth time you reuse a function like that. Well-done unit testing can also have a payback time frame of under a week, in my opinion. You get bigger wins from listening to it guide you through the initial design that you will get from adding it later.
Swizec 13y ago
Usually it's when they get their first non-seed round of investment and realise their product doesn't let them grow as fast as they'd like. Products growing through sales can go without proper cleanup for decades. Friends have told me stories of single SQL queries taking upwards of 15 minutes to run (and then being rewritten in SQL+PHP that does the same in 20 seconds)
- mseebach 13y ago
  I've seen my share of awful (but trivially optimizable) queries taking forever to run - but can you elaborate on what PHP has to do with it?
  - Swizec 13y ago
    Just that PHP is considered slow compared to a RDBMS, but is much much quicker when used appropriately.
    - mseebach 13y ago
      Ah, so you're talking about moving some of the logic from the SQL into code? Yes, that can certainly give a huge boost, no matter what the language.

Actually, I find that it's usually when the ugly code starts to cost them more. Basically, it's a car without brakes. It will get you where you are going, but it would have cost less all together if you'd installed working breaks from the beginning.

blowski 13y ago
To use your analogy, is it better to have a car with no brakes now, or to save up for another year to buy a car with brakes? The problem with the analogy is that it's _obvious_ that you should save up another year because of the danger. But in startup-world, it's not obvious at all. To really abuse your analogy, if you're being chased by wild hungry bears, you don't care whether the car has brakes.
- jasonlotito 13y ago
  Brakes generally aren't expensive (obviously, this is all relative... but lets ignore that), so instead of waiting a year, your more likely waiting a few days at most. The cost of good quality code isn't expensive either, in the short term or even in the long term. However, for the un-or-misinformed, writing good code might seem higher. Indeed, I'll even go so far as to say that for less skilled individuals, good quality code might seem to increase the cost dramatically. > if you're being chased by wild hungry bears, you don't care whether the car has brakes. A little planning would mean I wouldn't be in that situation: bears and no brakes. Though, it's amusing coming up with ways I could find myself in that position. =)
- Swizec 13y ago
  The thing with good code is that it's cheaper than bad code. For instance: it takes me 8 minutes to run the full test suite of an app and make reasonably certain nothing is wrong. It takes me 2 hours to get the same assurance manually. And I'll miss most of the problems. Another example: I recently implemented a feature where the feature took ~5 days and fixing the whole codebase to make the feature implementable took 20 days. Had the codebase been using certain libraries correctly without ghetto-coding its own solution, the feature would take me ~5 days.
- jerf 13y ago
  I don't really like the casual acceptance of the total dichotomy between dirty and clean code here. I'll freely admit you don't always get to clean every bit of code and make it pristine, but on the other hand, with only a small amount of effort and perhaps 5ish years experience it becomes pretty easy to pump out clean-ish code at the same rate you can make an utter, total mess, and recover the value of your slightly higher effort in as little as a week or two, a time frame all but the craziest start ups should still be caring about. Being in a hurry may be license to be "a bit sloppy", but I think it's a mistake to give yourself license to make a total mess, and use your speed as an excuse. For instance, once you're skilled at programming, and assuming you're using a decent language (another thing your startup should be doing), it's at most only slightly slower to refactor something into a function that copy and paste, and that probably still wins on every level the fourth time you reuse a function like that. Well-done unit testing can also have a payback time frame of under a week, in my opinion. You get bigger wins from listening to it guide you through the initial design that you will get from adding it later.

Swizec 13y ago

Usually it's when they get their first non-seed round of investment and realise their product doesn't let them grow as fast as they'd like. Products growing through sales can go without proper cleanup for decades. Friends have told me stories of single SQL queries taking upwards of 15 minutes to run (and then being rewritten in SQL+PHP that does the same in 20 seconds)

mseebach 13y ago
I've seen my share of awful (but trivially optimizable) queries taking forever to run - but can you elaborate on what PHP has to do with it?
- Swizec 13y ago
  Just that PHP is considered slow compared to a RDBMS, but is much much quicker when used appropriately.
  - mseebach 13y ago
    Ah, so you're talking about moving some of the logic from the SQL into code? Yes, that can certainly give a huge boost, no matter what the language.