Everybody is autistic when it comes to specs

I recently found a fascinating article by an autistic wikipedia author on Hacker News. It's very well-written, but what stood out to me the most was a section on failures in communication:

communication model

In a basic communication model, the sender formulates the message, and transmits it to the receiver, who interprets it. The receiver also provides some feedback...If you apply this model to an oral conversation, you quickly see all the opportunities for miscommunication: From what the sender means, to what they actually say, to what the receiver hears, to what they understand, information can change radically, especially when you consider nonverbal communication. It's like a 2-person variation of the telephone game.

Autists typically have a harder time than neurotypical people at reading subtle verbal and non-verbal cues in this process, but I've found that even people that think they are great communicators often see a lot of change between the message they're trying to send and the experience of the receiver. I've particularly seen this in software development, where product, UX, or whoever is writing the spec believes they've produced a comprehensive, thorough treatment of how the thing should work, when in fact what they've done is be overly prescriptive in some areas and left big, gaping holes elsewhere. The result of this is often that what gets delivered by developers looks quite different (in terms of timeline, scope, or scale)

When I first started in product management at Education Elements, we had an offshore development team, and worked in an extremely prescriptive, waterfall fashion. I'd talk to customers (teachers and internal customers), work with UX to produce designs, spec out the designs, and send them to the dev team. Days or weeks later, get back their interpretation of my UX designer's interpretation of my interpretation of solution to the customer's interpretation of their problem. Especially combined with the language barrier, a lot got lost in translation, and it was really hard to ship quality product.

We're doing the scrum thing at PagerDuty, and while I'm agnostic about the particular methodology (lean/scrum/agile/kanban), what I love about iterative development is that it assumes that humans are terrible communicators. It assumes that specs will be wrong, that specs will be misinterpreted, that specs will be incomplete...and that the way to solve the ambiguity is to walk over to the person who you're trying to solve the problem for and ask them for more information, or to prototype your interpretation as quickly as possible and get feedback. Agile solves communication problems by taking them as a given and providing structures for fast failure and learning. We all know we're getting something wrong somewhere, so the game becomes collaboratively figuring out what as soon as possible, rather than wishfully pretending we got it all right at the start.

I'm curious about whether agile development is easier or more difficult for autistic or aspergers' folks. This article suggests that well-done Agile may create some welcome structure and predictability with defined sprint timeboxes, and a clear process for the change that inevitably happens during development. On the other hand, the increased face-to-face interaction can be difficult if you have a hard time reading non-verbal signals, and poorly-done agile may seem chaotic and uncontrolled.

That passes the sniff test for me, but not being on the spectrum, I'm not going to draw any conclusions. However, with the high neurodiversity in the tech sector, I think it's important for us to think not just about how the methodologies we choose affect our velocity, code quality, and business outcomes, but also how they enable (or don't enable) success for the different types of people on our teams.