There are two related concepts called "idempotence" in programming. One is the mathematical one that quicksort and Raphael talk about. Namely, given a mathematical function $f$, $f$ is idempotent if $f(f(x))=f(x)$. Or more algebraically, $f\circ f = f$.
The other notion that's common in practice and particularly for distributed computations is if an identical "request" is made multiple times, the system will behave as if it was made once. For example, an HTTP PUT is supposed to be an idempotent request so that it can be transparently repeated in case it's suspected that an earlier request was lost. This sense of idempotence is important in distributed computing because it turns at-least-once semantics into effectively exactly-once semantics.
The second notion cast into the context of an imperative language would correspond to the property of a procedure or method that calling it once is the same as calling it arbitrarily many times with the same arguments (assuming no intervening related procedures/methods are called).
The second notion can be related to the mathematical notion by viewing the request/procedure/method as performing a function on the state of the system (taken broadly). An idempotent request/procedure/method, corresponds to an idempotent function on the system state.
Arguably, the response to an idempotent request should be the same on every request. In practice, the responses tend to be informational and so potentially non-deterministic (often due to the concurrency inherent in distributed computing), that you have no real guarantee of any response. For example, the MDN page I linked discusses the case of HTTP DELETE. A HTTP DELETE may return a 200 status code after successfully deleting a resource and then a 404 for future HTTP DELETE requests. But the non-determinism of networking means that making two identical DELETE requests could produce any of two 200 responses, two 404 response, a 200 response followed by a 404, or a 404 followed by a 200 response. (And, of course, many other possibilities such as a 503 response or no response.) The upshot is that your DELETE request could get a 404 response even when you expected a 200 response for a variety of reasons and thus, since the 404 response means the resource wasn't there at the time the request was processed*, you should treat that as just as good as having gotten a 200 response.
If the semantics of your procedure/method are: "on these arguments, do this, then non-deterministically return one of this set of responses", then the procedure/method is free to return different responses (from that set of responses) even when called multiple times with the same arguments. I would consider such a procedure idempotent assuming the "do this" part was idempotent. On the other hand, if the semantics of your procedure/method are: "on these arguments, do this, then if it is the first time this procedure was called return X else return Y", then I would not consider the procedure/method idempotent.
* Of course, someone could have added it back between the time the 404 was generated and the time you received it.