Problem Solving - Strategies?

Professional
21

[QUOTE=Demno;13978]I believe what he means is to break the problem into bits by testing half the potential problem at a time. I do this a lot with bugs or errors.
It’s similar to what Scott just described. Start big and close in.

Let’s say I get a crash whenever a certain object appears in the game. First I’ll try removing the object. Does the crash go away? Yes. Ok, so it’s the objects fault. After this I’ll try removing/replacing parts of the object. Try a different shader, try a different mesh, and so on until you find out where the problem lies.
It’s useful to write down what you have tested, and what gave positive results. I use tables for stuff like this.

Tip: Google “Half-splitting”[/QUOTE]

Yeah that’s pretty much my approach usually.

First you need to verify that the problem really exists and you can repro it. Then you just start removing pieces until you can get the problem to go away, and then start re-adding the removed pieces until the problem comes back. That usually means you have a fairly narrowed down piece of art or code which causes the problem and can start properly problem solving the real issue. Find the root cause of things is often much more work than actually fixing it. I’ve been around the block long enough that I no longer believe in blindly fixing things - “I think it’ll work now” just isn’t good enough. :slight_smile:

All this would be easy and fun if it’d be something you could run a real debugger on, but at least over here tech-art gets usually called in when the traditional methods no longer work. O:-)

SamiV.

22

Here’s another book recommendation that might be up your alley.

Rapid Development: Taming Wild Software Schedules

It was recommended on this reading list at Coding Horror.

“Rapid Development isn’t about rapid development. It’s about the reality of failure.” I haven’t read this one yet, but it sounds like a lot of good case studies and ways of avoiding some of the problems in the first place.

“in McConnell’s words, ‘read the instructions on the paint can before painting.’ Sure, it sounds obvious enough until you read this book and realize how rarely that actually happens in our field.”

23

stuff I keep telling the guys in my team:

  • take notes.
  • read error messages and logs.
  • ask questions!
  • use elimination of causes to narrow down the problem and move closer to its core.
  • don’t be afraid to get advice from other people in the team if you’re stuck.
  • visualize it: draw diagrams, timelines, etc. a picture can sometimes really say more than 1000 words.
  • write down your train of thought to better spot errors in your reasoning
  • last resort: ask TAO or google :slight_smile: