Even though it happens annually, teams building new visualizations often forget to think about the effects of turning over from one year to another.
In today’s fast paced, Agile world, requirements for even the most critical dashboards and visualizations tend to evolve, and development often proceeds iteratively from a scratchpad sketch through successively more detailed versions to release of a “1.0” production version. Organized analytics teams evolve dashboards within a process framework that include checkpoints ensuring standards are met for security, reliability, usability, and so on.
A reporting team can build a revolutionary analytics capability enabling unprecedented visibility into operations, and then, if year turnover isn’t included in requirements, experience embarrassing errors and usability challenges in the January after initial deployment. In effect, the system experiences its own Y2.xK crisis, not too different from the expected Y2K crisis 16 years ago.
I’d classify Y2.xK challenges in two categories: usability challenges and programming errors. Here’s an example of each category:
- Usability Challenges: Say a business customer needs to know status toward an annual goal. In June, an analyst might develop a report showing year-to-date progress in several charts and graphs. The report works great through the year, but then in January it’s empty because it was designed to show only current year data. At this point the analyst finds out that the report also supported users needing a rolling three month view. The analyst scrambles to add additional history to the report.
- Programming Errors: Some reporting tools allow comparing data of different datatypes. In Tableau, for example, you can compare an alphanumeric month with the value ’12’ with a numeric month with the value 12. If the report is developed in October that’s fine, because the two digit numeric matches the two character alphanumeric. But then in January the report fails because the numeric 1 no longer matches the alpha ’01’.
Here are two simple guidelines to keep in mind, or build into your development process, in order to prevent these kind of challenges when your dashboards cross their first year threshold:
- Include Previous Year Data: Discuss the year turnover challenge with your business customer, and encourage them to approve an additional year’s history, or a rolling 12 or 13 month view, to prevent loss of visibility after year-end.
- Simulate Year End in Testing: Figure out a way to make your visualization think it is the first of January, and see what happens. You’ll not only show your customer what the next January is going to look like, but you’ll also flush out any year-change-related bugs you’ve inadvertently built in.
Keeping the year change in mind can help you build visualizations that work seamlessly as the year changes, and prevent your own embarrassing Y2.xK crisis.