We need to take care in how we use the term “requirement” in development. Development requirements are really carefully crafted descriptions (distillations) of the “behaviors we care about.” They get assigned priorities and scheduled and (typically) only a small number of requirements are actually implemented in any given app release.
Ddevelopment requirements are usually NOT requiredHere’s my beef - development requirements are usually NOT required – they are, in fact, desired. …development’s goal is to fulfill desires – but desires are emotional and so we try to use requirements in their place (requirements are for the most part concrete and objectively measured). …of course, we can nail “requirements” and still build the wrong thing and fail – so development cannot escape their true lot in life - to build the most desirable apps possible – and app analytics suppliers are no different – we are subject to the same laws as every other development niche (it’s just that our users are all app stakeholders of some sort with their own users that are not our users).
A silent killer of application analytics implementations…and herein lies a silent killer of application analytics implementations (and what sets this specialty apart from other analytics categories); app stakeholders care more about app user satisfaction than the app users themselves.
Think about it, if an app user doesn’t like an app, they just stop using it (or go with a competitor). …but when users drop your app, you’re out of a job. So – before an app analytics provider can even think about fulfilling their users’ desires – they must first ensure (and prove) that they “do no harm” to this murky, extended user community once removed; and this is a genuine “requirement” in the truest sense of the word.
Why is this a “silent killer” that exclusively stalks application analytics implementations? Because application instrumentation (the generator of raw telemetry – step one of any app analytics implementation) must either run inside a client’s application (or inside the same runtime “looking in”) – application instrumentation can never be a part FROM runtime applications – it is unavoidably a part OF each runtime application. …and, application user desires are not the desires of application analytics users.
…so, as the great Stevie Wonder has written in Songs in the Key of Life (As), “…make sure when you say you're in it but not of it You're not helping to make this earth a place sometimes called Hell.”
It is a true requirement that app analytics instrumentation cannot, in any way, impact an app user’s satisfaction. If (and only if) this requirement is satisfied, will an app analytics solution be given the opportunity to fulfill its users’ desires (desires like “show me feature usage” or “send me exceptions”).
How can instrumentation fail? Lots of ways sadly – but the most common revolve around performance, stability, security, and privacy at runtime (recall that the expectations that must be met are those of the app user – NOT the app stakeholder).
Stay tuned – I’ll be posting my suggestions on how to distinguish what you may require from what you may desire.