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.

Activity Enhancements

Right now I'm working on enhancements to the v8 Activity. The list of featurs includes:

1.) More control over how utilization is calculated, including options to control how down time, off shift time, blocked time and processing time are used.

2.) Activity State Statistics are being added so the user will be able to see on the results tab the percentage of time the Activity spend in the busy, idle, down, off shift and blocked states.

3.) There will be an option on the Block Animation table to show the Activity State Statistics as a Pie Chart either at the same level as the Activity or on the icon of the enclosing h-block.

4.) A plot button to show how behavior of the random distribution chosen.

Begin by Modeling the Data

Modeling the data.
Earlier this year I saw a very impressive fleet management model. It was not all that large or even very complex. It was, however very flexible. By changing only the data in the model, it could represent any kind of fleet from cruise ships to delivery trucks. The key to the success of this model was that the model builder began by structuring the model data.

Often our first impulse is to approach a simulation problem by dropping blocks onto the model worksheet. This is partially our fault as a software developer. We have made it so easy to create a model that it is hard to resist dropping some blocks onto the screen and getting the instant gratification of a running model. Once the blocks have been connected together then you can begin the task of fitting the data to the model. While this may work fine for smaller, well defined systems, the build first, data later approach makes it difficult to create scalable reusable models.

Starting by designing a database for the model has a number of advantages:

1. You will know early in the modeling process what data to collect.
2. Data problems can be identified at the start of the simulation project.
3. Opportunities to create smaller, more elegant models may be discovered. Patterns in the data often point to reusable model segments that are identical in structure.
4. The data will fit more naturally into the model.
5. Fewer structural model revisions will be required to fit the data into an already completed model.
6. People who do not know anything about simulation can be part of the design process.
7. Your models will be more scalable.

So, before beginning your next project, rather than flowcharting the process, try flowcharting the data structures. You will probably become a better modeler.

davek