Wobbly chair of sports software

A few weeks ago, I made Sportscode. Hudl, watch out.

Well, actually, the point is that Hudl doesn’t need to watch out, because - alas - there is a difference between a working DIY video clipping bit of software and an actual product.

A regular theme of Get Goalside over the last year or so has been that football clubs probably shouldn’t all be tech companies. Now, part of that is because tech companies are increasingly susceptible to megalomania, but part of it is also practical advice.

The world of software engineers is currently split between those who love ‘generative AI’ coding tools and those who think they’re kinda trash. In the ‘love’ camp are people who like to move fast and break things. In the ‘trash’ camp are people who don’t like things being broken. (No but seriously; tools introducing bugs that are hidden because of a lack of oversight are basically the main complaint).

My version of Sportscode has a video player, custom-assignable hotkeys, an option to export to XML, and was created in about four hours (which, to be totally honest, feels slow). What it doesn’t have is any infrastructure that makes me trust it won’t crash if I try and code half a football match.

And yet, and yet, and yet.

The fact that someone with a passing grasp of React (the Javascript framework that it’s written in) can ‘manage’ a coding tool through the task of creating a fully working DIY app does change the landscape for football clubs.

I think the nature of these code generation* tools still means that you shouldn’t be using them to set up critical infrastructure, but developing, say, an quick, basic expansion to an existing set of regular reports for coaches; or a webapp to let players interact with their data? Seems more plausible.

The downside, the major downside, with any of this ‘small team employee-produced’ software is that, while they’re at the club, they’re the creator and the support desk and the bug-fixer. If and when they leave, you don’t care so much about the first of those roles, but you’ll probably still care about the other two. (That’s a large part of why you don’t want to build critical infrastructure this way too).

Another way that it changes the landscape is that what can be done with these tools will change depending on the user’s knowledge level. The tools probably become more powerful the more advanced the user is, for a similar reason as to why experienced line-managers with domain expertise can be useful. Part of managing is delegating, and part of managing is experience-sharing. ‘Ah, this sounds like a problem I’ve experienced/read about before, have you tried this?’ can be surprisingly powerful. People without coding experience - or without much of it, or without much football experience - can do the delegating with code generation tools, but they can’t do the experience-sharing.

Bundle that together, and the value of a fairly-experienced data-and-tech-person may have gone up by more than a fairly-entry-level one. And that’s quite interesting.

As a serial metaphor-er, I’ve been searching for the right comparison for the way that these code generation tools lead to changes. Basic as it may be, power tools of the ‘normal DIY’ kind are probably the best thing.

Imagine everyone had access to materials and power saws and belt sanders. Everyone on your street would, in theory, be able to build you tables and chairs for your business. You probably wouldn’t want them to, unless they could already build something sturdy. But there’d be uses for it. You might be able to redo some cupboards. They might be able to replace some faulty chairs in a pinch. Again: not critical infrastructure, things that have some common templates to follow.

What kind of DIY jobs do you consider doing yourself at home and what do you think is best to get a professional in for? Those same kinds of dividing lines seem applicable to the new age of DIY software in football clubs.

Hudl don’t need to watch out. Not yet, anyway.

*I am loathed to call everything ‘AI’. The major innovations have been around language models and their surrounding infrastructure. This doesn’t quite mesh with the term ‘generative AI’ which briefly had some time in the sun, because a lot of value comes from language interpretation as well. But the coding tools specifically tend to be useful because they produce code, therefore ‘code generation tools’. Let’s all remember that we don’t need to use the buzzwords that companies trying to show value to investors try to coin.