[AllegedAlec]

I once joined our support team to talk with one of our clients (I'd written a new bit of functionality and they wanted me there in case they would ask technical questions). It was one of the most eye-opening experiences ever. Our client talk about their clients abusing our software in ways that we as a development team had never even thought about.

EDIT:

On the other hand, I don't think it should be done to create a sense of urgency for developers. They are not going to work better if they also have to worry about each and every emotion that's being displayed in support emails like the example in the article. That's just creating a sense of responsibility in your company by appealing to emotions and guilt.

[_red]

We do retail / light industrial automation stuff.

Every so often (rarely but say once a year or so), we bring some members of dev team along on an install. Its always very very eye-opening for developers to see what 'problems' look like in the field.

Further, something devs miss about installs is the lack of infrastructure you have to deal with (on a new build-out for example). So saying 'Just download latest version X and install on each of the clients' will take 5x longer than it does in comfy office environment since it means: (a) Go to hotel or tether phone and download 1GB file over 3G, (b) Put on USB stick, (c) go to each client, disable all USB restrictions and install new software, re-enable all restrictions (d) do all this while power is being turned off / on because electricians are still working.

[mercer]

Could you elaborate on the kinds of abuse you saw?

[AllegedAlec]

> Could you elaborate on the kinds of abuse you saw?

In a very broad sense, sure. I don't want this account to be traceable to where I work now, so some details will be changed or omitted while keeping the kind of abuse the same.

We make a website where our clients can make timeslots available to the general public. The length of a timeslot is dependent on how many people the person booking slot intends to bring, as well as some other factors. Whether a person can book at a certain time therefore (partially) depends on how many people they tell our clients they'll bring.

We also made it so that the booker can change how many people will be coming along (for example because of sickness), or, if they are delayed, by how much, so our clients can more fully use all of their available resources.

However, how bookers were often using it, is by saying they'd come alone (if you have a very short timeslot, there's a better chance it's still available), and then change the number of people to how many were actually coming along. Or they'd just book a slot at the start of the day, and then delay it until they were placed on the time they actually intended to come. In both of these cases, they were abusing features which were genuinely needed for the product to work to their own advantage. It was slightly naive of us as developers not to take this sort of behaviour into account.