Indirection, Interfaces, and Control Inversion

I’ve been working on some existing code that has a reputation for being very difficult to understand. It’s taken a while but I’m feeling pretty comfortable with it now and it’s not that complicated. Part of what makes the code inscrutable is a combination of too much indirection and control inversion (no documentation doesn’t help, of course).
Indirection is calling code that calls code that finally does what you want.
It’s great for abstraction. For example, do you really know what happens when you write

i = i + 1;

Indirection gives you more flexibility (i.e. polymorphism). It’s what novice programmers fail to do. When you see 200 line functions, duplicated blocks of code, and hardwired values that constantly need to be changed it’s code written by a newbie.
When you see an execution path like

Class1::doit() -- Class1::doit2() -- Class2::doit() -- Class3::doit()

it’s from someone that learned their novice lessons but hasn’t learned the cost of indirection.


C# and GC (Garbage Collection)

Good overview of diagnosing memory related problems