"The user will never need more than n objects of type x". Sometimes this is unavoidable, but it is problematic.

The problem is a variant of the "magic constant" problem. In code, you should avoid using literals for constants because the meaning is obscured and the code is hard to change when the user collective wants to expand the software (I use "user collective" advisedly, as representative of my disbelief in the unary User).

But the "magic constant" problem also occurs at requirements and design time. I always get worried when developers use sentences of the form "this value will never be bigger than X" where X is a constant.

This is because the statement soon enough becomes a shibboleth, insider knowledge the possession of which tells the MIS people, at some level of their subconscious, that in the excess of the user collective, they are in possession of Knowledge.

The problem with this form of Knowledge is that the user collective is usually kept in the dark until its business or other activity expands past the point supported by the secret number, and boom.

Unfortunately, the MIS people then engage, often, in a *schadenfreude* festival, laughing at the clueless Users who don't know, as does the MIS community, that there are limits.

The expansion of the business becomes an annoyance and an indication of a sort of indiscipline to the MIS people.

A few years ago, I was talking to a friend, who does embedded software, who was all happy because the User had assured him that blocks of data for a new cellphone would never, ever, exceed 512 bytes, which meant for him that he could use a "simple" allocation algorithm.

I did not share his innocent joy, because IF the cellphone is a success, THEN the vendor has to come out with an even cooler phone, able to do more stuff, and this will expand the data block size...in all probability.

There is in fact a straightforward linked list method for allocating fixed-length blocks of arbitrary size, but assuming 512 bytes meant that the developer would be able to use a "simpler" (in the narcissism of equating simplicity with one's own capacities) array.

This is the sort of experience that makes me glad no longer to be an American programmer, because American programming praxis insists on this false pragmatism. And it's of a piece with Bush telling a dinner last night that he just can't understand why the Iraqis are so darn ungrateful for so pragmatically ruining their country with Rumsfeld's "simple", shitty, come-as-you-are, coalition of the willing, evil little war, another patch, another crude solution to a much larger problem.

Dijkstra asked, how do we tell truths that might hurt.

As far as I know we just tell them, but not like Cartman. We can tell the truth without saying, "hey buttmunch, you don't know SQL server!".

Or, like their teacher, without saying, mnghokay and annoying them and making them crazy.