Qlik Community

QlikView Documents

Documents for QlikView related information.

What do you ask the leaving QlikView Developer?


What do you ask the leaving QlikView Developer?

In-Memory BI technology is fast growing and QlikView is one of the leader in this arena. 4-5 years back recruiters and other IT folks hardly knew about QlikView. However, that has changed drastically and there are good number of opportunities. This change also impacts average tenure of an employee within the organisation. Not just QlikView consultants, it also impacts the permanent QlikView Developers. While we might see a common pattern amongst the Qlikers hopping from ship to another, it’s important to manage the transition process. We need to arrange a code review preferably in the last week and here are a few important things you would like to ask the leaving QlikView Developer (In no particular order):

1. Documentation with Screenshots: Without any doubt, application documentation is essential for any QlikView application. Application documentation is different from code comments, both are important but they have different purposes. Application documentation summarizes information about the following points:

  • Application architecture (i.e. 2 tier or 3 tier layer)
  • Reload schedule
  • Task dependencies
  • OnOpen or OnPostReload triggers (if any)
  • Number of tables
  • Number of columns
  • Number of rows
  • Number of concurrent users
  • Total number of users
  • Macro Code/ VB Script (if any)
  • BAT file(s) (if any)
  • Extension Objects (XML, CSS & .JS)

I’m sure we all plan & schedule application review(s) in the final week with the leaving developer. However, sometimes you might forget or rush things due to lack of time. So, having this high level information is very useful for a replacing developer to take over the work from the leaving QlikView developer. We can have this documentation either in Microsoft Word or Powerpoint and preferably defining a template would standardize the process.

2. Source Control Check-In(s): If you’re a big and organized shop then most likely you will be implementing source control system like SVN. Whether all the developers work from the development server or local machines, it’s important to check if the leaving developer did “Check-In” on last coding day. This ensures that we have up to date code base and even if the IT team archives or removes leaving developer’s data, we don’t lose anything. This potentially avoids contacting the leaving developer to ask – “Where is the latest version?”.

3. Code Comments: One of my favourite quote by Martin Golding - “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”. Although this might sound as exaggeration but it helps if we start taking code comments seriously. Imagine a scenario where you can’t get hold of leaving developer and you need to debug the application to fix an issue. Code comment(s) is the map to the labyrinth of leaving developer’s left brain. Having code comments is obvious but we miss them sometimes, so it’s important that we make sure every developer writes up code comments. If possible, read the code comments in the leaving developer’s code review and then look at the actual code to see if they are in sync.

4. No reference to Local Path on his/her local profile: I’m sure most of you use the relative paths instead of absolute paths in QlikView script. At times, while the application is in development phase we might work with absolute paths instead of relative paths. This is accepted as we have time pressure and deadlines to meet. But it’s important not leave any local path(s) in the code, especially with any lookup or mapping excel files.

5. QlikView Security & Other Password(s) : You need to check if there are any back door entry password (i.e. QlikView passwords) within Section Access. Ideally, you shouldn’t use the QlikView passwords if you work within a specific domain with active directory. But we all agree some implementations do need the QlikView passwords. Either way, it’s our responsibility to check if there are any QlikView passwords. Also, check if the leaving developer knows ODBC or OLEDB connection string passwords. Finally, double check if you need to know any service account password(s).

6. Manually Pushed Buttons: We need to know if there are any manually pushed buttons. This might be data dumps or export to excel activities, we wanted to continue the process and potentially consider automating the process wherever possible. Meanwhile, it’s important not to stop this manual process which might have great impact on the business.




Honored Contributor

Hi Deepak,

Great Post!!!

Very Useful.



Valued Contributor

One more good post from @Deepak Vadithala

Thanks for sharing such a great knowledge with community people......


Thank you Venkatasreekanth and Nagaraju, I'm glad it's useful.

Contributor II

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”

Nice one.

MVP & Luminary
MVP & Luminary

Don't put you name in comments. Work with a alias... 😉

Esteemed Contributor


good one! I also like the one about the psychopath - though I would rather imagine that the guy who gets to maintain my code is a dummy not knowing a thing about what the app is even supposed to do.

Documentation is essential, that's quite right - though I would rather propose (if deadlines allow it) to make the documentation and commenting as-you-go and not all in your last week - then your motivation will be relatively low and it will all be rather fast and a bit humble-jumble.

New Contributor III

Thank you


I'd ask, what's the hidden script password you domeass?

MVP & Luminary
MVP & Luminary

‌A real developer doesn't need a password for "hidden" script, since it's not hidden.. 🙂

New Contributor III

All good stuff.

Version history
Revision #:
1 of 1
Last update:
‎2014-12-22 09:56 AM
Updated by: