Rejuvenating Autoconf

Posted Oct 26, 2020 15:42 UTC (Mon) by nix (subscriber, #2304)
In reply to: Rejuvenating Autoconf by marcH
Parent article: Rejuvenating Autoconf

So... you think it is fallacious for Autoconf-using projects to be annoyed at being forced to throw away a lot of work and rewrite it, including all its baked in knowledge, and possibly find that you can't even do the shift to a new build system because the new build system is inadequately capable and can't do things you could do with the old one?

It seems entirely reasonable to me to look at that massive pile of work, not one bit of which would benefit your users and some of which might well harm them, and say "hell no".

Rejuvenating Autoconf

Posted Oct 26, 2020 17:40 UTC (Mon) by marcH (subscriber, #57642) [Link] (4 responses)

> So... you think it is fallacious for Autoconf-using projects to be annoyed at being forced to throw away a lot of work and rewrite it, ... ?

I just spend time double and triple checking my comment. While I clearly warned it would lack nuance, I didn't write anything remotely close to this.

Some good stuff in the rest of your comment but when the first line is deliberately and totally making up what the other said then the discussion can only go nowhere fast. This is much worse than not making an effort to understand each other. I've noticed "deliberate straw man" has unfortunately become the most common "discussion" style nowadays, role-modelled from the most obscure forums all the way up to the highest level of politics but I'm still refusing to "adapt" to this. Looks like we both have something old we like to cling to :-)

Rejuvenating Autoconf

Posted Nov 1, 2020 2:07 UTC (Sun) by jschrod (subscriber, #1646) [Link] (3 responses)

Sorry, but your "sunk cost fallacy" post the comment was about is exactly of your lamented "straw man" kind.

Pot, meet kettle.

Rejuvenating Autoconf

Posted Nov 2, 2020 9:02 UTC (Mon) by marcH (subscriber, #57642) [Link] (2 responses)

I'm afraid you lost me, sorry. In case that's relevant: "sunk cost fallacy" is _my_ perception of autoconf maintenance, has been long before this discussion and I didn't mean to attribute it to anyone else.

Rejuvenating Autoconf

Posted Nov 2, 2020 10:08 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

Except you are projecting YOUR values onto OTHER PEOPLE. *Bad* *Idea*.

The sunk cost fallacy is when you choose not to switch to a cheaper option, because of what you've spend on the more expensive option. It seems quite clear here that for many people, the cost of switching is very high, because they will have to (in one form or another) - reimplement a lot of autoconf. This makes maintaining autoconf the cheapest option!

Cheers,
Wol

Rejuvenating Autoconf

Posted Nov 2, 2020 17:01 UTC (Mon) by marcH (subscriber, #57642) [Link]

The sunk cost fallacy is by definition subconscious and it's a natural tendency we all have. This is very far from attributing a very specific, made-up point to someone specific.

> The sunk cost fallacy is when you choose not to switch to a cheaper option, because of what you've spend on the more expensive option.

The sunk cost fallacy is subconsciously give value to something that has none anymore and let that influence you. Influence is not always enough to win an (often collective) decision.

Sunk costs are much complicated in software than in say finance because _knowledge_ of an existing system is valuable: it makes knowledgeable workers much more productive which is of course very valuable, especially from the perspective of the experts. But what about the value for the project as a whole? The value of newer build systems is of a completely different sort: they require less expert knowledge and many more people can and do help with their maintenance. Interestingly, this decreases the "market" value of the old experts.

> It seems quite clear here that for many people, the cost of switching is very high, because they will have to (in one form or another) - reimplement a lot of autoconf. This makes maintaining autoconf the cheapest option!

It's pretty obvious that the minute after flipping the switch away from autoconf, a project that just migrated has spent a lot and gained nothing yet. I don't think anyone questioned that. Every technological choice is a large investment and its value must be studied _over time_.