Yes, we all have them.

And we will have them again, so it is better to accept the fact and try to get smarter in order not to waste a lot time.

This is just a small anecdote and some sort of catharsis but comes with and advice that distills obviousness.

Let's imagine that we have a very complex object that contains several hierarchies. This object is the result of a transformation of a domain object in order to better be rendered on a complex web page.

I'll try to describe the shape of both object (domain and presentation) but roughly the domain object contains a list of elements that are related to a container object. The presentation object inverts this relationship and has an outer container that contains a collection of inner containers that have a collection of mapped elements. The tricky thing is that this outer container contains also a collection of mapped elements. And I say tricky not because the design is flawed (it has to be like that for this model to ease our presentation demands) but because those mapped elements are value objects in the broader sense of the term: they is a new instance for each input element, meaning that if we map twice an input element (a domain object), we will get two different instances of the presentation object.

Confused? I am, so you might be too. Let's try to depict the situation:

That's a beefy picture!! I like them big. And we have not even talked about what the elements contain!

So if we add up caching of PresentationElements to the cocktail and spice it with a bit of change request and a bit of overconfidence in the knowledge of the objects we will get a hangover with bug headache.

My big mistake was assume that in the control which data I wanted to change was displaying the PresentationElement list of the OutterGroup.That caused several hours of awe when debugging this stuff (as our units tests were passing based on my assumptions) seeing that the value of the element was correct in the watches but incorrect on the screen.

Then I shared my awesomeness with some fellows and the developer that changed this code the last. We were chasing framework bugs that will make us famous when the problem was in my outdated assumptions about how the model was rendered as he pointed out in a moment of my despair.

Advice: aim for the basics. Always. Question yourself and everyone. Always (but do not be a jerk to question the correctness of numerical addition of the .Net framework).

And now I feel better with myself... keep on working in' useful stuff