4 ms·

I saw some reviews that claim the books just presents common knowledge. Keep in mind it is aimed at undergrads. I personally think the author is to harsh on "t

by lixtra 8y ago

I saw some reviews that claim the books just presents common knowledge. Keep in mind it is aimed at undergrads. I personally think the author is to harsh on "tactical programming" (solving problems locally without the big picture in mind). I agree with someones note on HN that tactical programming is fine till you get a product market fit. Technical debt has not to be paid back if the product fails. I try to design strategically for overall architecture and don't care for most of the rest (in worst case you can refactor later). If 9 out of 10 startups fail you can have huge savings. If you have enough success that it matters then you have the resources to improve.

dvfjsdhgfv 8y ago
I think your comment reflects well the mindset difference between programmers working for startups and the rest of the world. When you're working on a system that's supposed to last for decades, you think in a completely different way.
- coldtea 8y ago
  >When you're working on a system that's supposed to last for decades, you think in a completely different way. Some of the worst systems I've seen were those designed to "last for decades". https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
  - dvfjsdhgfv 8y ago
    I was thinking about the other end of the spectrum like Voyager probes.
    - coldtea 8y ago
      That takes a whole other approach yes. But that's also not the same as "to last decades". A lot of the old space code was used and dismissed after a few years / missions. The key difference is not "future-proofing" but "proofing" in general: the code had to be absolutely robust. https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
    - pc86 8y ago
      Code written on/for a space probe is certain the 0.01% in terms of safety and robustness required.
- chosenbreed 8y ago
  Do general purpose line of business programs last for decades though? I suspect that the ones that have lasted have gone through enough iterations to the point of being unrecognizable to original authors...
  - planetmcd 8y ago
    Even if it lasts for 5 years, that is still a long time to maintain and so the advice in the book is solid. As a business, you may want or need it to last longer.
  - _pmf_ 8y ago
    Not just LoB, also EDA software, specialized industrial and automotive testing / HiL software and general equipment control software where you can never start from clean slate because there's existing hardware in old production lines with a 10 year support contract. I.e. basically everything non-web/non-mobile has a higher lifetime.
  - TeMPOraL 8y ago
    Someone on HN said recently that business software is like another employee. You wouldn't fire a senior with lots of domain experience, on whom critical processes are dependent, just because it's time to freshen things up.
    - deleted 8y ago
      [deleted]
planetmcd 8y ago
I've not seen this 'common' knowledge in the field enough to call it common. While there can be a strategic value to just getting something working, the tough part is that many times that is used as a crutch to do no more thinking or design, quite possibly because they've never been called to. And refactors happen less than they ought to. The point is to be strategic about when to turn the quality/speed dial towards speed and know you are consciously taking on tech debt.

by lixtra 8y ago

dvfjsdhgfv 8y ago

I think your comment reflects well the mindset difference between programmers working for startups and the rest of the world. When you're working on a system that's supposed to last for decades, you think in a completely different way.

coldtea 8y ago
>When you're working on a system that's supposed to last for decades, you think in a completely different way. Some of the worst systems I've seen were those designed to "last for decades". https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
- dvfjsdhgfv 8y ago
  I was thinking about the other end of the spectrum like Voyager probes.
  - coldtea 8y ago
    That takes a whole other approach yes. But that's also not the same as "to last decades". A lot of the old space code was used and dismissed after a few years / missions. The key difference is not "future-proofing" but "proofing" in general: the code had to be absolutely robust. https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
  - pc86 8y ago
    Code written on/for a space probe is certain the 0.01% in terms of safety and robustness required.
chosenbreed 8y ago
Do general purpose line of business programs last for decades though? I suspect that the ones that have lasted have gone through enough iterations to the point of being unrecognizable to original authors...
- planetmcd 8y ago
  Even if it lasts for 5 years, that is still a long time to maintain and so the advice in the book is solid. As a business, you may want or need it to last longer.
- _pmf_ 8y ago
  Not just LoB, also EDA software, specialized industrial and automotive testing / HiL software and general equipment control software where you can never start from clean slate because there's existing hardware in old production lines with a 10 year support contract. I.e. basically everything non-web/non-mobile has a higher lifetime.
- TeMPOraL 8y ago
  Someone on HN said recently that business software is like another employee. You wouldn't fire a senior with lots of domain experience, on whom critical processes are dependent, just because it's time to freshen things up.
  - deleted 8y ago
    [deleted]

planetmcd 8y ago

I've not seen this 'common' knowledge in the field enough to call it common. While there can be a strategic value to just getting something working, the tough part is that many times that is used as a crutch to do no more thinking or design, quite possibly because they've never been called to. And refactors happen less than they ought to. The point is to be strategic about when to turn the quality/speed dial towards speed and know you are consciously taking on tech debt.