Hacker News Reader

Comment by lixtra | Hacker News Reader

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.

View on HN

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.

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.

>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

I was thinking about the other end of the spectrum like Voyager probes.

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

Code written on/for a space probe is certain the 0.01% in terms of safety and robustness required.

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...

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.

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.

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.

Reply on news.ycombinator.com