Paragon Simulation

19/10/2021

𝐖𝐡𝐚𝐭 𝐜𝐚𝐧 𝐛𝐮𝐬𝐢𝐧𝐞𝐬𝐬𝐞𝐬 𝐝𝐨 𝐭𝐨 𝐩𝐫𝐞𝐩𝐚𝐫𝐞 𝐟𝐨𝐫 𝐭𝐡𝐞 𝐟𝐮𝐭𝐮𝐫𝐞? A return to Business As Usual leaves business vulnerable to the next big, unexpected, disruptive event.

Improved efficiency through virtual scenario modelling

23/07/2021

Is the future you’re planning 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗔𝘀 𝗨𝘀𝘂𝗮𝗹 or 𝗪𝗵𝗮𝘁𝗲𝘃𝗲𝗿 𝗜𝘁 𝗧𝗮𝗸𝗲𝘀?

Listen to Vinod's conversation with Tim Richardson of Inter Consulting about the operational impact of Covid-19 on our business, and what challenges the future might bring.

How do you plan when the future is uncertain? What ideas and strategies have you put in place? Nod has shared his experiences and observations but we'd love to hear yours too in the comments below.

Is the future you’re planning 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗔𝘀 𝗨𝘀𝘂𝗮𝗹 or 𝗪𝗵𝗮𝘁𝗲𝘃𝗲𝗿 𝗜𝘁 𝗧𝗮𝗸𝗲𝘀? Tim Richardson of Iter Consulting invited me to record...

04/12/2020

Tip 6: Use Functions
A well-constructed model will contain Functions as these enable you to:
- Avoid duplicating code
- Simplify the model
- Examine the model’s internal data
- Make it easier to make changes

For extra credit:

Write “Test” functions that call the model Functions with a range of valid and invalid Parameter values to check that the Function is robust.
Write “Inspect” functions that reports the values of arrays, element states, etc. which you can use as the model is being developed.
Keep track of how frequently a Function is used by the model – then work to make it as efficient as possible provided always that it remains correct.

17/11/2020

Tip 5: “Assert” values before use
The essential idea is that Variables/Elements values are usually set outside the model e.g. in an Excel spreadsheet, and then these values are “read in” by the model.

Assertion is not the same as error handling. Assertion is primarily used during development and testing so that you can write better code, whereas error handling is to ensure that run-time errors are presented meaningfully to to user for them to fix.

14/09/2020

Tip 4. Don’t use hard-coded values
Instead use Constants. Hard-coded values are offensive! It’s so easy and more meaningful to use a Constant instead.

For extra credit:

Identify Constants by using all caps in the name
Initialise all Constants at the same time at the start of the model e.g. by placing them in an initialisation Function.

07/09/2020

Tip 3. Use a naming convention
A common technique is to use a short prefix (1-3 characters) on a variable/element name so you know the variable type.

For extra credit:

Make each Variable name meaningful
Do not “re-purpose” the Variable to have more than one meaning
Where possible refactor the model (i.e. rename the Variables) to keep the names meaningful.

04/09/2020

Tip 2: Declare all variables
You're in danger of using a Variable incorrectly,& if you mis-spell its name the software will create a new one “on the fly” & will probably have a 0 value. Revealing itself at some stage when the model is being tested, usually as a run-time error.

13/08/2020

A test-able code. The more modular the code, the easier it is to develop tests to prove the code is accurate. You should write code assuming that things could be wrong – this is called “defensive coding”, and it forces you to think about how to handle unexpected situations.

13/08/2020

Keep the code modular. If you find yourself copy/pasting a block of code a couple of times, this is a sign that you ought to consider creating a Function that reproduces its purpose in a generic way, so that it can be re-used.

13/08/2020

Keep the code understandable. Consistent use of indents and comments, meaningful Variable and Function names, and clarity of purpose results in readable code, and if the code can be easily “read” then it is more likely it will be understood.

13/08/2020

Make code manageable. On my computer monitor I can see & absorb about 50 lines of code at a time. I would suggest this is a reasonable max length of a block of code. This includes comments, so a block that is more than 35 lines of executable code is a candidate to be split up.

13/08/2020

Simple code: Some write code to be as compact as possible, but it’s far better to split a complex one-liner into 3/4 lines. It makes is easier to see what’s happening. negative - the more code there is the more chances there are for errors. So make sure every line is error-free!