Here’s a story from an early morning the other day.

I’m working on a small team that supports a web application with a lot of users. Not exactly Facebook scale but its not an internal business application. We have a few customers who pay for customizations of our app for their users. Someone on another team in my company noticed that one part of that customization wasn’t working.

After investigating the cause, I determined that the issue was happening with every customer who bought the customization.

####The Cause Our web application has some old-fashioned ASP.NET pages with code-behinds. In one of our code-behinds, there was a check to see if a particular image on a particular page was configured to use a customization or the default image. After checking for the configuration, it made sure that the customized image actually existed on the directory using File.exists(...). If that check failed, then it would fail-back to the default image. This is a code-path that ideally would never be traversed in a production environment.

So, natually, that code-path was always traversed. Even though the custom images existed, they were never served. The default and custom images were hosted on another one of our web applications, so File.exists(...) wouldn’t have ever worked. A WebRequest would be the only way to succeeed in that check, and that is still dependent on how that other web application is implemented (and also a completely ridiculous idea).

Anyway, so I propose a simple solution to my team: remove the check that the image exists. This code-path shouldn’t ever happen anyway. We have complete control over what is and what is not on our servers.

That idea is rejected by the team - “We need a failsafe in case the image doesn’t exist”. Okay, I can understand that. The bugged way of accomplishing this - checking for the image using File.exists(...) server-side wouldn’t work, so we need something else.

After some research, the solution seemed obvious (after all this isn’t exactly solving the halting problem): add an onerror event client-side:

MyCustomizableImage.Attributes.Add("onerror", string.Format("this.src = ''));

I propose this solution to my team. Their response was “Now that we’re familiar with the code, the fail-safe isn’t neccesary. Just remove the check.”

####The Effect This original solution is also perfectly reasonable, but I coulnt’t help but feel frustrated for the rest of the day. We did implement it and pushed it out in a timely fashion. For all intents and purposes, this issue was totally no big deal at all.

The reason for that is the actual point of this story is that I was really upset that I went through the energy of coming up with a solution and having it thrown away twice, and I’m coming to find that writing this kind of thing out here lets me deal with it.

A problem presented itself. My original solution was rejected, I came up with another solution, then that was rejected back for my original idea. Twice I came up with something and it was rejected.

The Ikea effect states that we find things to be valuable if we make them ourselves. When my ideas were thrown out I felt like value was being thrown away, even though my original idea ended up being implmented. I still felt it as a double-rejection.

Noticing this, I can see my reaction was immature and I’m glad that I can just learn from it. I am glad that I did not act on my frustration.

The lesson to learn can be summarized by a quote from Harry S. Truman:

“It is amazing what you can accomplish if you do not care who gets the credit.” Harry S Truman

p.s. How this got past us is in the first place is a big argument for writing more unit tests. However, that is an argument for another day.