Categories
Game Development

The devil is in the details

I just finished adding the ability to read double clicks. There’s a lot of little things you have to consider: You have to click the same button twice, not two different buttons rapidly in a row You have to account for mouse drift of a few pixels from the last click location Triple clicks should […]

I just finished adding the ability to read double clicks. There’s a lot of little things you have to consider:

  1. You have to click the same button twice, not two different buttons rapidly in a row
  2. You have to account for mouse drift of a few pixels from the last click location
  3. Triple clicks should not count as two double clicks

The reason this is noteworthy is that it’s a good example of how trying to write TDDs that handle every detail of the code is impossible because normal people don’t think at that level of detail. I was watching this show about autistic people and how some of them remember all the small details they see if you let them glance at a room. A normal person doesn’t because they are bombarded with information and the brain filters out most of it.

This is why I take the approach “Write what you know, refactor what you don’t.” This is totally opposite the concept of high level design.

It’s also why, when you ask for a spec from a customer, the spec invariably misses out on details. Programmers are trained to do this sort of work and forget things. What can you expect from a customer who probably barely knows how to open Word? Extreme programming accounts for this by involving the customer in the design and implementation process which sounds like a good approach.

Leave a Reply

Your email address will not be published. Required fields are marked *