As a developer, I have found that most systems analytics tools can be both an important asset and an unnecessary expense. Their usefulness, in my experience, is ultimately determined by the size and stage of the company. If the company is at a low funding stage, the cost of some of the more advanced analytics tools just isn’t practical. If they have the funding, but not the traffic, the benefits of analytics are completely negated by the lack of data to… you know… analyze.
The same goes for the team size. Analytics tools can be incredibly useful to any size team, however after a certain level of growth a large Development team will likely split into two separate departments: Development and Operations. At this level, these tools tend to be delegated to Operations, leaving Development free to focus on the whole developing part of the job.
So, your development and operations departments are still on one team (it’s likely both jobs are shared by everyone on the team), and your company has the right amount of funding and traffic to justify the cost and need for a systems analytics tool. But how do you choose from all of the available tools out there?
This is a question that can bring any developer in a leadership role to their knees because the effects can last for years. I’ve always found that tools that can be isolated apart from the core application itself are always the best choice in this situation because they often take a language agnostic approach and, in case you don’t like them, they can be hot-swapped for another service with minimal effort.
Being able to easily undo a poor decision shouldn’t be the only measuring stick you use to make your choice. The type of data you can get, and how accessible it is, are both far more important than being able to hit the reset button. As a developer, when dealing with third party applications, there are three things that I look for: usability, accessibility, and visibility.
We all know about usability. It’s a popular buzzword that is thrown around a lot in the startup world but, if you ask me, it is doubly important when dealing with full-stack tools built for developers. Full-stack tools are often more in-depth than standard consumer products. Rather than only requiring good UI/UX on the application frontend, a good full-stack platform requires a lot of foresight in the backend as well. There is nothing that turns me off more than API-as-an-afterthought. Systems analytics tools almost always fall under the umbrella of “full-stack tools” because they are designed for developers and non-developers alike.
While the application itself should be easy to navigate and use, it is just as important for the API to be clearly documented and logically architected. The more time I have to spend dealing with integrating something that isn’t directly related to the product, the more likely I am going to cut my losses and pick something that was designed with my needs in mind.
While a systems analytics platform may be managed by just one person initially, as the team grows, it becomes exceedingly impractical to keep the knowledge isolated. The one thing that will cause my to ditch a tool immediately is a lack of multiple account management. While there are some great business tools for password management, I would prefer that everybody on my team has their own login. This is a major security concern for me. If we let somebody go (or they quit), I would rather delete their account than have to change a password and disseminate it to the rest of the team.
Having easily viewable data should be a no-brainer for an analytics platform, but you’d be surprised how often I come across tools that do a very poor job at actually doing what they’re supposed to. Showing me pretty graphs and tables isn’t enough, though. I want control of the data. Let me import, export, manipulate, search, and filter it. If the time it takes to get raw information is longer than the time it takes to actually read and understand it, there is something wrong.
Ultimately, the most useful systems analytics tools I’ve ever worked with do an amazing job at getting out of the way. They don’t try to predict how I want to work and they don’t limit my ability to get what I need, they simply give me the tools to do things my way. While this probably clashes with the common million-features developer mindset, in practice, simple can often be significantly more powerful.
About the Author/Zachary Flower
Zachary Flower (@zachflower) is a freelance web developer, writer, and polymath. He has an eye for simplicity and usability, and strives to build products with both the end user, and business goals, in mind. From building projects for the NSA to features for Buffer, Zach has always taken a strong stand against needlessly reinventing the wheel, often advocating for using well established third-party and open source services and solutions to improve the efficiency and reliability of a development project.