Posted: January 12, 2013
My friend and former colleague John Batteh and I often encountered a problem that we called, for reasons that will become clear, the "Your Baby is Ugly" problem.
John and I have had the good fortune to work with and/or be exposed to a lot of really excellent models. But often, these models are "trapped" inside tools or methodologies that are unnecessarily limiting. Frequently, you look at some interesting model and you think "Wow! That is a really cool model". Clearly, the person who developed this model has a keen understanding of the underlying physics which is always great to see.
However, John and I often worked on the process side of modeling and often what happens is you talk to the person who created the model and try to suggest a way to improve the model by saying something like:
You know, you could get even more out of this model if you...
That's where the trouble starts.
Despite your best intentions and respect for what this person has managed to create, often what they hear is:
Your baby is ugly.
This is a problem that has plagued me over my career. No matter how tactful, diplomatic and constructive you try to be, there is no escaping the fact that people put a lot of pride in their work and I often find it difficult to navigate the treacherous terrain of critiquing it.
This is why I think modeling standards are so important. They allow us to capture models in a way that transcends tools. This "frees" the models and keeps them distinct from the particular tools or environments they were authored in. This kind of flexibility then widens their potential impact and allows them to transcend the limitations of any particular tool.
In the end, modeling is essentially software development. However, since it is strongly aligned with an engineering mentality, there is an interesting and inherent conflict that arises. While the software development community is often looking for the "latest and greatest" technology to extract the greatest efficiency, engineering tends to focus on what is "tried and true" in order to avoid getting the wrong answer. Model developers are often caught in the uncomfortable middle ground.
Share your thoughts
comments powered by Disqus