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.
Thursday, November 19, 2009
Making the Transition from ExtendSim Modeler to ExtendSim Developer
Subscribe to: Post Comments (Atom)
For the past several years I have been wanting to learn Python as it has been growing in popularity. Recently I decided to take a few course...
Is it possible to build an agent-based simulation (ABS) model in ExtendSim? Certainly. We recently helped build a model of the intensive c...
I recently had a discussion with a scheduler at a manufacturing plant. I was trying to explain to him the benefits of simulation, and I thou...
Did you know you can run models simultaneously in ExtendSim? Yes, you certainly can. That feature has been in ExtendSim since v10 was rele...
It is an excellent idea to make a backup of your model from time to time. This could be useful if you want to go back and open a previou...
Below are some best practices for modeling. Document first Don’t wait until the end of model development to start the documentation ...
I taught a one-on-one ExtendSim class a few weeks ago. The student asked about ONLINE resources a new modeler should be aware of. Gr...
Post a Comment