One of my goals with the survey component was to ensure that it was extremely lightweight, consuming the absolute minimum of resources. Doing so requires not only a good database design and access patterns, but also necessitates the addition of potentially error prone caching and optimization code: Building a little survey component is trivial, but trying to do so while ensuring that you hit the database as seldom as possible, all while personalizing for each user and avoiding "vote stuffing", gets a lot more interesting (and, quite honestly, fun. Straightforward projects are never fun).

I mention this because it's always a tough debate - a good percentage of issues in the field have occurred because of this sort of optimization, with caching in particular being the root of a lot of issues.

As an aside, I don't plan on sticking a survey on each and every entry - in fact they should be quite rare, such as when a topic is particularly contentious. The survey with this entry is just for fun.