Qlik Sense: The Dashboard Is Pretty But The Script Is a Crime Scene

Read time: 2.5 minutes

How to Prevent Creating a Nightmare From Your Qlik Sense Scripts?

1. An explanation for each resident load is needed.

Resident loads are not inherently bad... however, an unexplained resident load is.
Solution: Add a comment on the purpose of each resident load to help others understand why the load was created.

2. An aesthetic final table that cannot be traced is great, but not production.

Clean outputs may look good, but they do not imply that they are a reliable system.
Solution: Keep a standard mapping of source to transformation to final table for ease of tracing.

3. Temporary tables should not be permanent, but disposable.

If your temp tables are numbered for version control, you have a problem.
Solution: Ensure temp tables are cleaned up at the end of the process and establish a naming convention for these tables.

4. Only change the name once, not five times.

Multiple name changes can destroy trust and create challenges for debugging.
Solution: Establish a centralized approach to naming conventions early in development, and keep it consistent throughout code changes.

5. If you are the only one who knows how to run the script, you do not have Qlik; instead, you have created a dependency.

The concern of "it works" may actually present a greater risk of not being able to reproduce than originally thought.
Solution: Conduct a bus test in February with a new analyst to determine if they can successfully change one KPI, then reload the document within 48 hours.

💡Key Takeaway: 

The end result of a Qlik load script may be aesthetically pleasing, but the process of creating the end product might have been fraught with issues that you loved/hated. Ultimately, the goal is not to create pretty dashboards but to produce a logical framework that will last longer than the next person to open the file.