Before the web, my database design experience almost always required third normal form [en.wikipedia.org].
On the web though, that division of data across multiple tables can really really kill performance. (If you need to perform multiple joins so that people can see the basic info in a list or grid view, you're doing it wrong.)
I think we've all heard time and time again how well users respond to fast sites. Speed for the user has to trump the obsessions of database admins for clean design. ;)
What I've found best is to mix the two approaches. I keep a really clean database structure underlying everything I do, but I also have what I call "cache" columns or sometimes entire "flattened" tables with some joined data and calculated data. Those are used to speed up querying the data.
In your example, I'd have a column in the `questions` table called `answer_count_cache` that is updated any time an answer is added or deleted. If database changes are possible outside of that code, I'd also run a cron at a reasonable interval to double check that the value is correct.
This really, really comes into play when you need to do something intensive like, for example, ranking the questions by how many pageviews they've received. Your pageview table will be enormous and there's just no way you'll be able to afford to run a 3-4 second query to spit out how many views each question has received in the last week/month/lifetime -- just to rank the questions in the first place.