Brad Stenger, is a researcher and journalist, currently at Georgia Tech Wearable Computing Center and NYU Center for Data Science. His articles have appeared MIT Technology Review, Wired.com, Ars Technica and TIME. Twitter: @bradstenger.
An athlete performance coach for a professional team showed me her in-season workflow. This was in August 2016, after the season. She relied most on two apps, one for monitoring athletes’ wellness and a second that tracked training loads from games and practices. Her daily reports with crucial key performance indicators were handcrafted in Excel, then cut, pasted and emailed to the head coach. She had a multiplier to connect four high-capacity thumb drives to her USB port. While her apps kept their data in the cloud, she needed lots of player data local, on her machine, to do the Excel calculations and graphs.
Her situation is far from ideal but it is the norm among practicing sports scientists. The profession has forced them to become technical experts unto themselves with tools, methods, inputs and outputs that are unique to their specific sport and team. The work is hard, and it is made more difficult because she is mostly on her own. Help, to the extent it is available, comes from peers who also use lots of technology but also don’t get much formal training to improve their technical skills.
“It’s unfair what’s being asked of these people,” says Kevin Forbes, who works on athlete performance products at Kinduct Technologies, makers of a widely-used athlete management system, based in Halifax, Canada. “There are hundreds of companies and products. They’ve all got their niches. Performance staff have to understand all these vendor solutions and then put them together. Whatever they come up with is going to be unique for their players and their team.”
Our anonymous coach/analyst has her process and it works for what she needs. She maintains a strong sense for her athletes’ fatigue, readiness and injury risk. During the 2016 season there was a period of intense travel with a hectic game schedule but the evidence showed the athletes had the physical capacity for peak performance, no matter the conditions. The team lost a crucial, hard fought match that brought the season to a dissatisfying conclusion. The team had the physical ability, displaying it repeatedly, but the creative and cognitive processing to mentally outperform the opponent wasn’t there, not on that critical matchday.
Get The Latest Sports Tech News In Your Inbox!
Despite the effort that goes into her data and analysis, she’s frustrated. She has yet to take all of her physiological and performance data and effectively combine it with game statistics to gauge how well her players are playing. Players in every sport have been known to run all day, sprinting like demons, and still have disappointing game performances, sometimes because they ran too far or too fast. All performance coaches and analysts face a similar dilemma. They can work and work, and they might never find the path that leads to all the answers they want from data.
For many sports organizations there is no clear cut path for their sports performance directors to get the most from their data and technology in the time they have available. The reasons are complicated but mostly boil down to issues around end user programming, a term that refers to software users who haven’t been trained as computer programmers but who rely on an informal kind of programming to get their work done.
The job description for working in athlete performance now includes end user programming. Unfortunately, those tasks are limited by what vendor software allows athlete performance professionals to accomplish.
Ravi Ramineni is a performance data analyst with the Seattle Sounders sports science group. Before joining the MLS soccer team he worked on products for Microsoft. He’s a full-fledged programmer who knows commercial software better than many sports tech vendors. He stepped into a situation common throughout the industry. “When I first joined the Sounders,” says Ramineni, “there was no formal system here. Everything was on a couple of spreadsheets.”
End user programming is critical in industries that rely on human intelligence but where the basic workflows change as new, disruptive technologies are introduced. Examples from the recent past of industries that experienced complete digital transformations are accounting and graphic design. Mastery of the new digital workflows involved minimizing the tedious and repetitive elements, often with end user programming, so that these “power users” could focus on the more enjoyable, intellectual aspects of their jobs.
The Sounders’ Ramineni is an example of a sports technology power user.
“It’s an order of magnitude difference” in productivity, says Brian Dorn, referring to the bump in what power users can accomplish. Dr. Dorn is a Computer Science professor at the University of Nebraska-Omaha who researches end user programming. According to Dorn, three typical use cases describe end user programming tasks: automating a process, projecting ranges of possible outcomes and recreating functionality from another digital workflow.
In sports, automating communication tasks to help with collaboration is a frequent end user programming objective. Automating communication also can be an unmet opportunity. Even though sports is intensely collaborative among the coaches, athletes and staff, the communication channels provided in vendor software products are limited. Everyone would like to communicate more but bandwidth exists for only the highest priorities.
“Most of the code is throw away code,” adds Dorn, meaning that it’s never going to be incorporated into a larger code base, or likely to be seen by anyone besides the person who wrote it. Because authors are not trained in programming they lack the vocabulary to benefit from traditional computer education instruction. Dorn’s research has shown that tools using contextual cues from the specific problem domain have better outcomes than basic how-to instructions for non-traditional programmers. When programming is treated as problem-solving, like it often is in sports, the solutions are frequently suboptimal. Quality tools for end user programming are a significant help in achieving better user outcomes.
The lack of formal computer programming vocabulary causes two problems for end user programmers. First is how time-consuming the programming problem solving is. “It’s hard to come up with the questions that lead to an effective solution,” says Dorn. The vocabulary obstacle can be intimidating, prompting users to look for answers among peers instead of reaching out to technical experts. The second problem is that errors in code can propagate, as both wrong conclusions and incorrect procedures, sometimes to the harm of the broader community.
Users are not the only participants in an end user programming situation. Technology vendors are trusted technical advisors for the sports communities they serve. Vendors that work with customers to improve the tools that support end user programming get a window into the enhancements and features that will improve their software products.
Effective end user programming is an indicator of the healthy working relationship between software vendor and customer. By providing tools for users to customize and automate tasks vendors get to focus on the larger, more significant features that will help greater numbers of customers. The alternative for a vendor is to pivot the business model from a technology to a service orientation that internalizes the issues that could have been tackled by upskilling end users and enlisting them as programmers.
Commercial software is a lowest common denominator business. Even niche software needs to have a broad enough solution to attract enough customers and remain commercially viable. Sometimes the lowest common denominator is too low however. The functionality for a complete customer solution isn’t in the product.
After the Sounders hired Ramineni, he set about checking into technology vendors. “There are a lot of products that would accomplish some of what you needed, but then there would be some features you needed but they wouldn’t have them. And then they always have some features that you don’t need,” he shared. A team “can only say ‘we want this feature’ but then the software company is going to build it only if 20 or 30 teams ask for it.” Teams’ priorities rarely align with vendors technology development priorities.
End user programming is a way to move past the lowest common denominator and reach higher levels of customer success. Customer service is another way to elevate customer success. Between the two business models, customer service is easier and more vocal but it’s also less sustainable, as customers don’t learn as much about how their needs and the technology go together.
When my colleague at Georgia Tech Wearable Computing Center, Clint Zeagler, talks with software users in sports and asks them what they’d like to accomplish with technology he hears the same answers, “It’s what their vendors tell them to expect from technology. A lot of times it’s a message that comes from marketing. It’s not an in-depth technical understanding of the problem or the solution.”
The mostly silent majority of end user programmers in sports have taken what they’re given and adapted it to meet their needs. Vendors don’t fully see the opportunity that comes from helping performance coaches and analysts to help themselves, seeing them level up to become power users. As a result, sports technologies that should improve aren’t getting better fast enough to really benefit teams and athletes.
More than one NBA strength coach at the recent NBA Combine told me that 80-hour work weeks are commonplace. Productivity improvements from better software tools will directly improve quality of life throughout the sports professions.
The way to better end user solutions might not come from the products designed for coaches and teams. They might come from the consumer market for wearable health technology. Products intended for recreational athletes and mass consumers have, out of necessity for large user bases, well-developed interface and interaction designs.
Steve Oney leads a research effort at the University of Michigan to define and create end user programming tools for recreational athletes. Google already offers a toolset called Fit that programmers can use to create applications with health data on Android devices. Apple Health is a similar platform for Apple devices.
Recreational athletes, Dr. Oney feels, are a place to start getting end user programming in sports to a better place, “There’s a huge number of goals that recreational athletes might want to go after, more than what you could include in an ordinary targeted application.” Give a user the right tool, something that fits the situation and helps handle the data, “then whatever the goal is, it’s within reach.”
Kevin Forbes says that Kinduct provides lots of user control and flexibility in the product’s setup interfaces. It lets a coach individualize training plans for athletes and then manage those relationships. When it comes to integrating with other vendors’ products Kinduct has a range of partnerships but a standard practice to not make recommendations, says Forbes.
Ramineni and the Sounders have had success with a system they developed in-house, something Ramineni designed and built for flexibility, to blend different data sets in ways that make the collected data greater than the sum of singular data sources, and for speed, to rapidly generate new, custom reports.
“Things keep changing,” he says. “We have the reports we send out to coaches at the beginning of the season and, by the end of the season, they have changed a lot.” The effective end user programmer stays on top of those changes, managing and updating the dynamic inputs and outputs of their system.
“Either you buy a platform that solves 90 percent of your problems, but then you need somebody that can do that 10 percent left over,” he added. “Or you need someone that can build something specific for your use cases, for your needs. In both cases you need someone. There is a role that needs to be filled.” The role requires skills that are different from what coaches and trainers are paid to do, according to Ramineni, “You need a programmer.”
The point: unless sports technology developers improve the tools for more of their users to build their ideal solution, the end user programmers for their products will exist on the margins. Some teams with deep pockets and technical knowledge will recognize the human resources need for trained programmers, but most sports organizations will continue to struggle with their technology.