I gave up always-on connectivity for Lent.
Well, truth be told, that wasn’t quite how I planned it. It just happened. On my most recent trip out-of-town I was worried about theft and damage more than I normally am. Given that a “normal” business trip for me often involves third world cities with 90% unemployment and an hourly murder rate, you can guess what horror I was dealing with: teenagers.
So this is what I took:
That’s a Nokia 110 and a very old IBM laptop running Linux. The laptop did have Wifi, but no bluetooth. The Nokia had a very basic bluetooth, but has no capability to tether a laptop for internet access.
I’m not a luddite so I set myself up with the best I could using the hardware available. That’s a modern Linux distribution — which in itself is interesting: no one would try doing serious work on a Windows 98 system, which is probably what that laptop once ran.
Between bouts of nostalgia, I paused for reflection: roughly 15–20 years ago I was running something very similar to this kind of environment, and I was often to be found programming in the lobby of some hotel after delivering a tech class in some distant city. What have we gained, and what have we lost?
Not being online was a moderate challenge.
Perhaps a bit of better planning (both short-term and long-term) would have resolved these problems. Maybe if I’d chosen GnuCash or OpenERP instead of Saasu accounting wouldn’t have been a problem. I could have carried around a physical GPS device, or taken some cheap device that could run google maps offline. I could have cached lots of documentation (as I used to do), but a lot of websites and tutorials don’t lend themselves that very easily. I could have installed a Slack client, but with long round trip delays it would have been functionally equivalent to email.
What surprised me is what I struggled with the most. Photography was terrible. I’m not a serious photographer, but I take quite a few pictures on my usual phone, which backs them photos up automatically after which they get turned into panoramas and stories and so on. But the Nokia camera has awful resolution, and I don’t even have a way of getting the pictures off it. We have raised our expectations of acceptable photos and videos very quickly in the last decade. This doesn’t seem to be slowing down, so what sort of cameras will we be using in 2025?
Then the other big problem was ergonomic. The laptop was clunky and heavy, it didn’t fit in my backpack very well and the battery life was terrible. It was probably mediocre at the time, but between the decay of the lithium battery and our increased expectations of what is normal, I found it frustrating. I was chained to the wall. I couldn’t move around or choose to sit outside to work for a while.
The Nokia had the opposite problem. It was so small I kept thinking I’d lost my phone, not realising that it was still in my pocket.
By running a modern Linux distribution, I took advantage of Linux’s heritage, steeped in a world where being off-line was normal, and internet connectivity was brief: a world where we aren’t bound to monthly subscription SaaS services.
I’m not being rose-eyed for the past: I’m aware that there were some serious limitations. But what I found fascinating is that there were some advantages.
This was all extremely illuminating given my most recent data science project which was for a famous company that runs a lot of software development projects.
I analysed around 200 projects and identified some factors that can predict when a project is going to miss deadlines. I’ve done this before for other customers — I’ve got it mostly automated for JIRA and it drives the smarts in http://www.queckt.com/ if you want to take a look at it.
In most organisations there is one extremely clear predictive factor associated with missed deadlines: the word “meet” or “meetings” appearing in a JIRA ticket. But this company runs development fully-remote. You don’t ever meet in person: it’s all communications via Slack, or teleconference or whatever else the team wants to use. So the usual “meeting” factor predicted nothing. It didn’t occur enough to be terribly useful anyway.
But what did predict a deadline in peril on a fully-remote project was the density of Slack communication. If there is intense back-and-forth communication with large numbers of messages being exchanged with short deadlines between the development team, then don’t set your hopes on the next release being on time.
At the time, my interpretation of this was simply that there must be a lot of confusion about what’s required and that a lot of communication is going on trying to resolve it.
But now I’m wondering: what if the Slack communication is not just a proxy for confusion? What if it is causative? When I couldn’t interrupt myself, nor be interrupted, I was far more productive. Programming is a cerebral activity — even more than writing — usually done alone: is it better to take long periods of uninterrupted thought — even if it means reducing communication with team mates?
This is not just an academic question. One of these two things must be true and the implication is obvious:
So let me announce here a project: I would like to measure this. I would like to create a distraction index measure, derived from corporate emails, instant messaging, and so on. Then I’d like to see how well the different distractions correlate with late projects, delays, milestone slippages, etc.
If you are in a company that has a good number of software projects on the go, and it’s worth a bit of money to you to know how to optimise your developer’s time, I’d like to talk to you. I’ve got code to analyse a bunch of other useful predictors too — such as the language used in git commit messages; the topics used in your JIRA tickets; and numerous others — so whatever happens you’ll get something worthwhile out of this.
Obviously, if you are working for Slack, or Atlassian or another instant messaging company, and you’d like to know your impact for better or for worse on your customers, I’d really like to talk to you as well.
Get in touch with me here: [email protected]