Simulation and Innovation

I remember, very clearly, the first moment that I saw Extend (now, of course, called ExtendSim). It was at a TIMS (a precursor of INFORMS) conference in 1993. At that moment I realized that I was looking at the future of simulation. This was an amazing program, a quantum leap in simulation technology. You could build a model by dragging and connecting blocks together. You could combine blocks together to create a single block. You could interactively change the model while it was running. You could create your own blocks. You could even program a block to do something when the simulation was not running. Wow!

At that point, I had already worked with a number of simulation programs (Siman, Slam, GPSS and more) but none of them could compare to the capabilities of Extend. What did I do? I asked for a job. After a rigorous interview process (I met everyone at Imagine that and did a little programming) and some pretty tough negotiations (they offered, I accepted), I started work. That was 17 years ago. The most amazing part of this story is that we’re still ahead of the pack. I’m even seeing some new simulation programs that look eerily like Extend did in 1993. I’ve heard some say that there has been no significant innovation in simulation software in the last 25 years. Extend came out in the 1980's - perhaps they are right.

Sense-itivity Analysis

Today I read a headline that said “75% Probability Apple Stays With AT&T”. That was based on: “"couldn’t find compelling evidence" that AT&T's contract with Apple ends this year. He gives it a 50% chance. Additionally, there's a 25% chance that AT&T would bid for -- and win -- another year of exclusivity. Add them up, you get 75%”.

Whenever somebody adds up probabilities, that sets off an alarm in my head. What if the analyst believed that there was a 60% probability that AT&T would get the new contract? Then the sum of the probabilities would be 110%. That’s a little more than absolute certainty, which never exists in the stock market.

The lesson here is to use a little, what I will call, “sense-itivity analysis”. Plug some plausible numbers in to make sure that the answer still passes a common sense test. We know that the probability must be 100% or less. In this case, it will certainly be less than 100%. So the result of 110% tells us that there is a math problem here. Doing a little “sense-itivity analysis” is a good idea in simulation models as well as the stock market.

For the record, the correct answer is 62.5%. I will let you work out the math.

Making the Transition from ExtendSim Modeler to ExtendSim Developer

It has been just over a year since I joined Imagine That Inc. to work as an ExtendSim developer. For me, this marks a return to software development after having taken a 15 year sabbatical to become an ExtendSim modeler. During that time, I had several different jobs working for small and large companies and as an independent consultant. Each of these jobs required the use of simulation to provide analysis and decision support for internal and external customers. Quite fortunately, I almost always had the freedom to choose which simulation technology to use. Naturally, I chose ExtendSim. While I had several reasons for choosing ExtendSim, my primary reason was based on the fact that no matter how difficult the problems and/or customer requirements were, I knew I could always find a way to deliver a timely, valid and effective solution using ExtendSim.

As a modeler, I was focused on searching for good problems to model, convincing people of the value of simulation modeling, and translating problems into useful ExtendSim models. As an ExtendSim developer, my focus has shifted from using ExtendSim to building components of ExtendSim. Instead of thinking about how to build re-usable models, I now think about how to create blocks that will make it easier for modelers to build re-usable models. At an abstract level, I see my job as having changed from solving customer problems to helping modelers solve customer problems. Needless to say, my previous experience generated a significant amount of empathy in me for simulation modelers. I understand how they are often required to provide answers for extremely complex problems with little time to construct let alone validate simulation models to solve these problems. I appreciate how modelers are being asked to incorporate increasing amounts of detail and data in simulation models and to integrate their models with other applications, particularly databases and web-based applications. I appreciate how difficult it is to convince organizations to adopt simulation as a viable component of their analytical repertoire. What excites me is being in a position to contribute to the evolution of ExtendSim so that it can better address many of the emerging issues facing today’s simulation modelers.

After working as an ExtendSim developer for over a year, I sometimes find the difference between modeling and developing to be a bit fuzzy in my own mind. Maybe this is because it is difficult for me to develop features in ExtendSim without having the experience of the modeler in mind. The major difference I see between developing and modeling is being feature oriented rather than problem-solving oriented. I like to think of ExtendSim as consisting of a collection of features that make up a “toolbox” of modeling capabilities. Modelers use the “tools” in the toolbox to build solutions for customers. My new job as a developer is to find ways to improve the ExtendSim toolbox. This means my days are focused entirely on designing, developing, implementing and testing software.

While I often spent entire days developing software as a modeler, the process of developing custom software to create features for a model is very different than developing features for ExtendSim, a software product. The main difference in developing ExtendSim features is a significant amount of energy has to be spent developing user interfaces. The vast majority of the software I developed as a modeler usually required either very simple or no interfaces. The situation as an ExtendSim developer is exactly the opposite. In fact, the interfaces I am working on as an ExtendSim developer are extremely challenging to build and test because of the many different possible states they can be in. All of these states have to be explicitly managed in the code. For blocks that require many dialog variables with many different possible settings, a large amount of state-management code must be written. To effectively manage all this code, I find myself relying on the same design principles I did as a modeler. In particular, I use the principle of modularization to look for generic patterns in the code that can be encapsulated in a function or procedure to contain a commonly used set of instructions. As a modeler, instead of looking for code patterns I looked for block patterns that could be encapsulated in hierarchical blocks instead of functions or procedures.

All in all, the transition from modeling with ExtendSim to developing features in ExtendSim has been pretty smooth. I am looking forward to contributing to the evolution of ExtendSim and getting feedback from the modeling community as the new features I work on are used.