> I’m not a mechanic or a farmer

So the author is looking at one third of the problem (from the perspective of an IT worker), in a comfortable stage-managed experience put on by Deere themselves. A sensor with a disconnected cable - a five minute visual inspection would have also diagnosed the problem!

I'm quite comfortable with computers. And yet when working on my own vehicles, anything that mentions "use the manufacturer software" is avoided unless it's impossible not to. For example my experience using Honda HDS:

1. Spend hours installing Windows in a VM, HDS software from dodgy forums (to avoid the even dodgier "cloud" offering), running an ethernet cable 75 feet outside to where I was working - when my goal was to have my hands dirty fixing the car.

2. Massively slow scan times. We're talking 20 minutes sitting there initializing its understanding of the bus by probing every device every time the software starts up. The software starts up a lot because every time it hits some unexpected condition it needs to be restarted. Every time you choose a different option to check something about another subsystem, the software needs to be restarted. Every time you need to check if you've made a permanent or temporary change, it needs to be restarted. Every time you actually get your hands dirty and make some change on the car, it needs to be restarted. And so on. Companies view these tools as pure cost centers, making it so embedded developers DGAF about any kind of robustness or polish.

3. No actual description of what can be set, or theories of operation of any hardware device. The best you get is references from procedures in service manuals designed to be blindly followed, and the corresponding button in the software that runs some black box procedure.

4. Along with that, the chance of touching a lot of things you don't really want to be touching! HDS made me reenter the VIN number every time it started up (which remember, is often), and I think this was actually writing the VIN number somewhere! I entered it wrong once and it appeared that I had actually changed something.

Now obviously Deere is not Honda, but I don't see a reason to expect this would be any better. And of course this is not even touching:

> Prices start at an annual cost of $195 per individual machine

All this overhead adds up when you're working on one or two vehicles in a personal-bespoke capacity. I'm never going to reach for that software again unless I absolutely have to, even though I know in theory it can tell me a lot in one central place. I'd rather simply model a vehicle's computers as black boxes. I'm sure if you're a Honda tech you develop a model of how the software works, what steps of the procedures to batch and when to pause and check things over, etc. But from an individual perspective where I've got one car to fix rather than one every day? It's utter trash.

Adding digital control networks to vehicles increases their inherent complexity. This is unavoidable, similar to adding any new system (eg ABS, 4WD, emissions controls themselves, etc). I think mechanics could respect that, if it weren't bundled with a whole bunch of unnecessary/accidental complexity including top-down surveillance/control. Knowing a thing or two about technology and engineering, what would I actually expect?

1. PDF documentation with thorough bus diagrams. For every node on the bus, documentation from its manufacturer - its theory of operation, the settings it has, the messages it reads from and reports to the bus, additional message/register definitions for what can be read by diagnostic tools. Everything that you'd get if these were DIP switches and LEDs rather than CAN messages.

2. Machine-readable descriptions of CAN PDUs published by the manufacturer themselves. All the message/register/etc definitions documented in the above files, in a well-defined format ready for use by third party tooling.

3. Third party libre software with the usual `make && make install` install path (ie easily incorporated into every operating environment) that uses those definitions to display bus messages in symbolic form, as well as craft new messages to tickle device functionality.

I think that about covers it - there isn't actually much here, it just needs to be documented! I know interacting with digital vehicle networks would still be frustrating for many, but people would eventually get over it and even embrace it - it should be more convenient to have the computers display what they're reading rather than having to work around them. Checking the computers first would become standard procedure if the tooling weren't so infuriating.

(For more context my own tractor is a Kubota with HP under the Tier IV threshold. I earnestly wish it did have a DPF - less shit to breathe in and less black crap coating my loader. But not at the cost of dealing with the current "state of the art" computer controls! I've also heard horror stories about long term Deere parts availability)

I fixed a tractor using John Deere's self-repair service. Farmers aren't sold