Along with being editor-in-chief of this magazine, I'm a full-time consultant. One of the many hats I wear includes being added as a lead developer/architect for my client's development teams. I want to talk about a current client who's a boutique-advertising company with extensive needs when it comes to client reporting. For many years, this company used Microsoft Excel as its standard tool for building reports. It was adequate, but this was/is a very costly way to create reports.
In August 2015, we decided to look at optimizing this process. We chose to build a pilot version of a data warehouse accompanied by the adoption of a more specialized reporting toolset. That summer, based on a client recommendation, we chose to adopt a tool called Tableau. Before making a purchasing decision about this tool, we performed a great deal of due diligence. This due diligence included setting up the skeleton of our data warehouse, creating some rudimentary dashboards, creating basic reports, and testing the basic workflow of adopting Tableau. We liked what we saw, so we made the decision to adopt Tableau as our reporting tool.
During this time, we had to replace the tool we used to perform statistical data analysis on our client's data. Initially, we used a tool called Stata for doing data analysis. We quickly found ourselves faced with data limitations along with limitations in automating this product with our company processes. Stata is a great product but its automation imitations couldn't be worked around. We decided to take a foray into the SAS world.
When it comes to statistical analysis, SAS is the 10,000-pound gorilla. I've been involved in SAS automation projects in the past and knew that this product would fit our needs. But I'm no statistician. Once again, we did our due diligence and created new data models using the SAS language and integrated a prototype system into our current .NET code base. Long story short, we made the decision to adopt SAS nearly a year ago.
Fast forward to today, and I find myself having a discussion with a colleague about the product adoption choices that we'd made. This discussion centered around the selection of Tableau for reporting versus using the built-in visualization tools found in SAS. The catalyst for this discussion came from one of our SAS analysts. This analyst was recommending that we move to SAS for reporting versus using Tableau. In no simple terms, I told my colleague “this is an inherently bad idea.” He praised my candidness and asked for details.
My answer was this: “Tableau is one of the ‘Cadillac’ reporting tools and specializes in client reporting. SAS is a statistical tool with a reporting tool bolted on. When it comes to finding people who use Tableau, the universe is vastly larger than it is for SAS. Tableau has sold billions of dollars of reporting software, so finding people capable of using it should be pretty simple.” My colleague took my comments under advisement. I'm not sure what will happen with that information but I did my best to avoid what I felt would be a mistake.
So now you must ask: “Rod, why did you spend that amount of time discussing product adoption?” Well, my Padawan (apprentice), this commentary was less about product selection and more about making decisions in a mature and rational way.
Now I want to focus a bit on the analyst who recommended changing reporting tools. I'm going to make a HUGE assumption about the analyst and his recommendation about changing reporting tools. The analyst is probably more comfortable with the SAS toolset versus learning the ins and outs of Tableau and is making a recommendation from the slice of the world he understands, while failing to consider the “bigger picture.” I'm going to attribute this to youth.
I'm not saying “youth” as in the age of the developer. I'm saying “youth” in terms of seasoning. You already know that cheese, wine, and Scotch get better with age. This same maturing applies to developers. A few years ago, a client had a security review of our development team and practices. One of the more favorable points was the number of years that our team had worked together. We knew each other's strengths and weaknesses, and we knew who was an expert at what. That's why the security reviewer gave us credit for the longevity of our team. Institutional knowledge cannot be overlooked.
Borrowing a term from Ted Neward's column this month, I'll describe myself as a “grizzled developer, with many years of scars.” Some might call this accumulated wisdom. Hopefully my 25+ years as a developer have given me some insights when it comes to making decisions and how they can last decades. For the record, I've made many decisions that long affected me and my clients' development over the years. Some of the decisions were right on and others have acquired a bit of stench over the years.
The point of this editorial is not to pick on the analyst that had the “temerity” to challenge an assumption but to show that some decisions are made for entirely different reasons than you might think. Some of us choose the “old and dependable” versus the “new and improved,” based on years of experience and many scars and battle medals.
