[njarboe]

This is the future of learned helplessness. People that see problems and inconsistencies in software systems and try to work around them will have worse outcomes than those that just blindly follow the workflow assigned to them.

Seems like one needs to be controlling the spec and writing the code not to get stuck in this trap.

[jaclaz]

>People that see problems and inconsistencies in software systems and try to work around them will have worse outcomes than those that just blindly follow the workflow assigned to them.

Well, not always.

That applies ONLY to those that find such problems or inconsistencies and workaround them in an incorrect manner.

And this brings us back right to Chesterton's fence:

https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence

that can be invoked both when users do silly things, but also when programmers do them.

[carlmr]

Never heard of Chesterton's fence before, and it's quite interesting, but I don't see this as applicable here. This was a design error on the part of the programmers, because the software didn't make it clear why it was "misbehaving".

[jaclaz]

> This was a design error on the part of the programmers, because the software didn't make it clear why it was "misbehaving"

Partly yes, but only partly, as they did publish the "peculiar" workaround that they (the programmers) used in the update (though not giving to it the relevance that should have been given to it), but NO user actually reads the boring text that comes with the updates of course.

In this peculiar case the non-reading users were divided in three:

1) non-reading users that didn't even notice the anomaly

2) non-reaading users that noticed the anomaly and that either read the accompanying text or called to ask why the anomaly presented itself and were given a reasonable explanation.

3) non-reading users that noticed the anomaly, but, assuming that the programmers were a bunch of good-for-nothing morons [1], forced or "overruled" the settings without asking anything (and of course without even asking themselves if they were possibly causing an issue later on)

Of course both the #1 and #2 were fine, with the difference that the #1 were simply lucky, whilst the #2 "deserved" their success, as they had the curiosity to delve deeper in the issue.

The #3 are the main reason why I posted the Chesterton Fence reference, but it is applicable more generally.

Now that they were (all, users and programmers, in different ways) bitten by the issue, most probably the programmers in next release will add a field to the database so that you can have more than one payment with the same government code on the same day.

Still I can bet that in a few years the new kid on the block (among the programmers) will notice that there is a field in the database that is always set to 1, the memory of the reason why that field was added will be lost and he will probably remove that field by saying "Ha! I optimized the database by removing an unneeded field." and falling in the same fallacy.

[1] BTW, not that the opinion specifically was completely wrong, though I am not a programmer (nor an accountant) I had to deal with some of these guys to import some inventory data coming from another accounting program and it was a nightmare.