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.