33 ms·

Work fast, don't think things through, make mistakes, pay for your haste by spending more time fixing your mistakes than you would have had you thought things t

Work fast, don't think things through, make mistakes, pay for your haste by spending more time fixing your mistakes than you would have had you thought things through.

wallace_f 7y ago
Not ideal, but mistakes and experiments seem to be the best way people learn.
- alimbada 7y ago
  There's nothing wrong with making mistakes in experiments. However, when you're building financial systems, there's absolutely no room for mistakes.
  - ptero 7y ago
    There is always room for mistakes if you start by building prototypes. In fact having first approximation prototypes allows one to catch mistakes in how systems and subsystems interact early and fix those at a fraction of the cost. Developing on a live fintech system is a different kettle of fish
  - deleted 7y ago
    [deleted]
  - perlgeek 7y ago
    Most financial systems are designed to have room for mistakes. Banks keep ledgers of transactions instead of just the balances, so that if an account balance is off, it can be recalculated from the transactions. Transactions can be cancelled in case there was an error. Invoices are often checked by humans before they are sent to customers, introducing an option to catch errors. If the customer receives a faulty invoice, they can contact whoever wrote it and ask for a correction. And so on. Of course, there isn't room for error in every corner -- having a flaw in an authentication or authorization protocol could be very costly to recover from. But in general, the assumption that in finance in general, there is no room for mistakes is simply false.
  - naasking 7y ago
    > However, when you're building financial systems, there's absolutely no room for mistakes Then I can assume that all of your financial software has verification proofs and/or is fully model checked? If not, then clearly there is room for mistakes even in finance.
avip 7y ago
Measure once, cut twice, earn one to throw away.
- skohan 7y ago
  This is a bad analogy for software. One of the unique properties of software, compared to other crafts, is that the material cost of iteration is virtually zero. We should use that to our advantage instead of pretending we're carpenters.
  - ensiferum 7y ago
    Often fixing fucked up shit takes more time than doing it from scratch but because of the system has been built around the fucked up shit you can't just throw it away and then you end up having to deal with continuously paying the higher than should price. In software the material cost is not the cost of a concrete material such as wood (like you mentioned) but developer time
  - kdelok 7y ago
    Even using the carpentry analogy, I suspect the point is to avoid ruining something on which a lot of time was spent. The material cost of most raw materials isn't very high, but ruining something you've already spent hours crafting is extremely costly. The other thing to bear in mind is that there is always more work to be done than time to do it. You have to factor in opportunity cost. As many other commenters have said, ultimately it's a balance which depends on your company's particular situation.
    - skohan 7y ago
      > The material cost of most raw materials isn't very high, but ruining something you've already spent hours crafting is extremely costly. Thanks to version-control software it's also incredibly cheap to experiment freely with an existing code-base in a completely non-destructive fashion. I see no reason to treat existing code as fragile or precious.
Nyandalized 7y ago
You can definitely go the other way to overthink a problem, even as high to induce the halting problem. Absolute optimization is mathematically impossible, and an imperfect choice has to be made at some point.
tehlike 7y ago
Sounds nice on paper. Reality is, you figure things as you go along. Plan for 6 months, and you will see you have 6 months of work.... Get to action first, and you'll have maube 6, maybe 7... Anyways...

Work fast, don't think things through, make mistakes, pay for your haste by spending more time fixing your mistakes than you would have had you thought things through.

wallace_f 7y ago

Not ideal, but mistakes and experiments seem to be the best way people learn.

alimbada 7y ago
There's nothing wrong with making mistakes in experiments. However, when you're building financial systems, there's absolutely no room for mistakes.
- ptero 7y ago
  There is always room for mistakes if you start by building prototypes. In fact having first approximation prototypes allows one to catch mistakes in how systems and subsystems interact early and fix those at a fraction of the cost. Developing on a live fintech system is a different kettle of fish
- deleted 7y ago
  [deleted]
- perlgeek 7y ago
  Most financial systems are designed to have room for mistakes. Banks keep ledgers of transactions instead of just the balances, so that if an account balance is off, it can be recalculated from the transactions. Transactions can be cancelled in case there was an error. Invoices are often checked by humans before they are sent to customers, introducing an option to catch errors. If the customer receives a faulty invoice, they can contact whoever wrote it and ask for a correction. And so on. Of course, there isn't room for error in every corner -- having a flaw in an authentication or authorization protocol could be very costly to recover from. But in general, the assumption that in finance in general, there is no room for mistakes is simply false.
- naasking 7y ago
  > However, when you're building financial systems, there's absolutely no room for mistakes Then I can assume that all of your financial software has verification proofs and/or is fully model checked? If not, then clearly there is room for mistakes even in finance.

avip 7y ago

Measure once, cut twice, earn one to throw away.

skohan 7y ago
This is a bad analogy for software. One of the unique properties of software, compared to other crafts, is that the material cost of iteration is virtually zero. We should use that to our advantage instead of pretending we're carpenters.
- ensiferum 7y ago
  Often fixing fucked up shit takes more time than doing it from scratch but because of the system has been built around the fucked up shit you can't just throw it away and then you end up having to deal with continuously paying the higher than should price. In software the material cost is not the cost of a concrete material such as wood (like you mentioned) but developer time
- kdelok 7y ago
  Even using the carpentry analogy, I suspect the point is to avoid ruining something on which a lot of time was spent. The material cost of most raw materials isn't very high, but ruining something you've already spent hours crafting is extremely costly. The other thing to bear in mind is that there is always more work to be done than time to do it. You have to factor in opportunity cost. As many other commenters have said, ultimately it's a balance which depends on your company's particular situation.
  - skohan 7y ago
    > The material cost of most raw materials isn't very high, but ruining something you've already spent hours crafting is extremely costly. Thanks to version-control software it's also incredibly cheap to experiment freely with an existing code-base in a completely non-destructive fashion. I see no reason to treat existing code as fragile or precious.

Nyandalized 7y ago

You can definitely go the other way to overthink a problem, even as high to induce the halting problem. Absolute optimization is mathematically impossible, and an imperfect choice has to be made at some point.

tehlike 7y ago

Sounds nice on paper. Reality is, you figure things as you go along. Plan for 6 months, and you will see you have 6 months of work.... Get to action first, and you'll have maube 6, maybe 7... Anyways...