Hacker News Reader

Comment by iterateoften | Hacker News Reader

That’s the opposite analogy. The OP is saying drive the car as much as possible and as long as it doesn’t have problems don’t mess around under the hood.

Some people tinker with adding mods and things to their cars which increase the probability of the problem.

View on HN

Using the engine analogy, a plane is a better example than a car. Especially as the mental picture of not surviving a crash is more vivid.

Would you rather fly on a plane that has been used daily for the same flight for the past 10 years? Or fly on a plane that’s either never flown, just got out of the shop, or hasn’t been flown in years?

If _nothing_ has ever been changed on the plane, I'll take the new one, thank you. I don't know how it lasted that long, but I won't take any chances.

Refactoring is analogous to changing the composition of the plane, rather than repairing newly broken parts with identical ones.

I'll fly on the 20 year old 737-700 and you can fly on the spanking new 737-MAX.

Oh, planes are a great analogy. If you insist on flying them without changing anything, you can even face some criminal charges.

But you also can't go and redesign the entire thing.

Please, at a minimum, change the oil according to manufacturer specs. Or eventually blow up your engine.

> The OP is saying drive the car as much as possible and as long as it doesn’t have problems don’t mess around under the hood.

If that's what you and the OP are saying, then you're conflating the codebase with the end product (program). Yes, the end user (at least in an ideal world) shouldn't need to modify the end product. That wasn't ever disputed, though.

The point (if I have to use your car-modding analogy instead) is the manufacturer's engineering team very much does need to be able to evolve the design (read: source code) for future versions of the car.

Reply on news.ycombinator.com