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!