Qlik Community

QlikView Documents

Documents for QlikView related information.

Five words QlikView Developers should never say...

Honored Contributor II

Five words QlikView Developers should never say...

Large/ Huge: Whenever you walk into a meeting room with the Business Analysts, Managers or Business Users who might ask how big is the application or data set? Don't say it's small/large/huge. Instead give the numbers because the words “small”,  “large” and “huge” are subjective to each person. Instead go prepared with the numbers ready in your head or written down if needs be (if you can remember then that’s best). Give reasonably approximate numbers if not the exact numbers: size on Disk, size in RAM, Number of Tables, Number of Rows & Columns. It's not so important to give precise numbers as they might be changing while you're talking. I compare these numbers with "Facebook Likes or Tweets" where we don't care so much whether it's 60,648 or 60K rows. Knowing the approximate numbers helps all of us to make informed decisions.

Never: As a QlikView Developer, we all are passionate about what we do. We always want to give the best solution to the business. In this process, we lay some rules around what is possible and what is not. Sometimes, these rules arise from emotional desire and we get into a bubble to protect our emotional desire. For example, In a large enterprise, we don't want to keep the ETL logic within QlikView. Instead we want to push the ETL logic to the upstream systems but sometimes this may not be possible. In this scenario, we will be asked to do the ETL in QlikView and it's against our development strategy. This situation can possibly trigger emotional desire to say - "We NEVER do ETL in QlikView". Although, this might not be a good practice, our emotional voice forces us to say "Never". Instead, we should advise the business of the potential risks with this approach and if possible give them real-life examples. Personally, I prefer to follow all the theoretical rules for software development on every project but this might not be feasible when you have to run a business.

Fast/Slow: QlikView AJAX performance has two fundamental areas of measurement.  The first - application session load time. This is the first place where users might see some latency. The Second - average query response time when user makes a selection. When someone complain about the performance it's important to identify where is the performance delay. Equally important is to quantify this, how many seconds/milliseconds. This way we don't have to rely on subjective experiences of whether the app is running “fast” or “slow”. Also, it's useful to speak with other developers instead of referring to fast/slow.

Sometimes: On occasion, we utter the words "sometimes" when code/logic doesn't work. When we say "sometimes" we are referring to the symptom of the problem instead of actual underlying issue. As a Developer we should know the underlying reason/root cause for code/logic not working. It's OK for users to say - "sometimes this functionality doesn't work while referring to a problem". This is acceptable because they are referring to the scenarios where they get unexpected functionality/results. However, as a Developer you can't use "sometimes" to describe a problem.

Report(s): There is common misconception on using the terms "QlikView Report" vs "QlikView App(s)". Lot of QlikView Developers tend to use these terms interchangeably but there is fundamental difference between these terms. Despite some amount of overlap, I see apps as more interactive and we use them as tools to discover an insight from business data. Whereas, reports can be static and sometime printed or published to PDF and they already have pre-designed  insights to provide reassurance of a specific pattern or event. Also, the term reports sounds like we are in 90's where we develop & publish the facts without allowing users interaction with the data.

Thanks to Brent Ozar for the inspiration!

www. QlikShare.com

Honored Contributor

Hi Deepak,

Good Post!!!

Points are very useful, a developer should incorporate above points in his day to day interactions with fellow developers, Business Analysts, Managers or Business Users.

Definitely a Plus.



New Contributor III

Hi Deepak,

Very useful...

Thanks for posting....



Not applicable

Thanks a lot Deepak

Contributor II

Very inspired.
Thank you.


Valued Contributor II

"Although, this might not be a good practice, "

Just out of interest. Is this your opinion. Or is this recomended by QV.

"Instead, we should advise the business of the potential risks with this approach and if possible give them real-life examples".

What are the risks? And what is a real life example?

I'm just interested to understand more regarding QV for large enterprises


Honored Contributor II

RJ - It's not my recommendation neither Qlik's recommendation. That was just an example to provide you context around - "Never" word.

In my opinion, it all depends on what business want. Some of them prefer to store the business logic outside QV and others don't mind.

Hope this helps!



Contributor II


thank for sharing. I think is very useful



Valued Contributor II


I thought you were giving an example based on what you believed.

Honored Contributor II

Thanks RJ. That's half true in some places I've worked and not true in smaller firms/projects. So I believe in it but it's not a thumb rule to follow hence I said I'm not directly recommending it. Instead, it depends on the project, client and budget etc.

Valued Contributor

Very thought provoking DV, I imagine most people reading (including myself) would agree and also know which ones they occasionally say


Version history
Revision #:
1 of 1
Last update:
‎12-10-2014 08:43 AM
Updated by: