House of pain: If YAML makes you swear, shout louder – the agony is there for a reason

Non-quoted string vest? Don't mind if we do

Column Enterprise IT is about solving problems, but for those who work in the field there's an index of irony in that statement. The further you go towards sales and marketing, the more problems are solved; the further towards the engine room of making this stuff work, the more problems appear.

Which is why JetBrains feels so comfortable talking about pain. The company has launched a cloud-hosted version of its TeamCity continuous integration (CI) system, which exists to manage the pipeline that all trendy IT shops have installed and through which the intellects of brave men and women are turned into saleable products.

The pipeline, you may remember from your days at dev school, replaced the waterfall of the ancients. By automating test and production and removing the hidden world of silos, smooth well-ordered efficiency could be married to rapid change. The marketing was impeccable, because the bad things about non-agile dev really were that bad. But guess what? Pain is still here. It's just moved around a bit.

In particular, JetBrains has identified the agony of YAML as being strong enough to justify their particular brand of analgesic. And it's true – claiming that YAML causes suffering is like saying cutting your toenails with a chainsaw will reduce your shoe size. The solution, says the IDE and domain specific language (DSL) company, is an IDE and a DSL.

Hold hard. How come devops, the saviour of the IT world, has this pain point in the first place? What did we miss last time? YAML is, admittedly, something of a hot mess. It has structural faults – syntactic white space may be the stupidest idea since God invented the pigeon – and allowing non-quoted strings is as unpleasant as clothes-optional day at a trampoline club. But most of the problem isn't really YAML's fault, it's that what it's being asked to do is specify and control unfettered complexity.

Is that anything else's fault? You can click the mouse pointer of blame on Kubernetes, which consumes most of the world's YAML and which, by dint of doing quite so many different things, demands quite so many ways of describing how they can be done. DSLs certainly hide complexity beneath prepackaged, tuned methods of handling them. But that complexity exists because, well, IT has to work in the real world and that's a very messy place. If you want to do something that the DSL isn't very specific about, the pain comes back.

Where does it hurt?

Perhaps the clue's in the pain itself. In the messy real-world system of our bodies, pain isn't just there to make us miserable – a task that it is admittedly extremely good at.

It's there to signal that a problem exists, define where it is, and provide feedback on any mitigation we can try. And as humans, we learn that many mitigations to reduce pain – gin, wildly inappropriate sex, Minecraft – can do more harm. For pain to do good, it must have feedback.

Marketing always claims to understand that feedback. We are clever people, we have found the solution by analysing it, buy our stuff. But we aren't part of that loop, except in the abstract. TeamCity may remove YAML misery, but what if you like, are skilled in and are very productive with, YAML? Having to learn an alternative is gonna hurt, sucka.

They don't mention that in the marketing. Which is not to say anything particular about JetBrain, who are undoubtedly fine people with a good product; it's true of any change in how complex systems work where the complexity is just part of the physics. You can find hundreds of tolls and techniques for soothing the agony of YAML, but which works? The pain moves around, but where is it truly least?

Let's replicate the useful bits of mammalian pain by teaching our robot servants to feel it. There are many ways to make computers feel pain, and by that feeling help define where it comes from and provide that feedback on mitigation. Sentiment analysis is the creepiest, with AIs analysing keystrokes, mouse twitches, pauses, vocabularies and facial expressions. You don't want management anywhere near that, it's one short step away from re-education camps and attitude adjustment.

But having a hotkey to mash when you're frustrated by a tool's intransigence or a badly structured lump of refactoring fodder; that could tell you over time where your own daily devils live, and across a pipeline, across a company or even across the industry – we're all connected, right? – then real information will flow, and not manufactured by a company with an agenda to push. Open source market research is far less stupid than making a tab and a space mean different things.

In fact, in almost every development environment known to humanity and most especially including those built out of home workers, the most accurate and least intrusive way of finding the pain would be to teach our machines to recognize, grade and collate swear words. There is no finer, better modulated vocabulary for expressing pain, and our machines are finally up to the task of parsing our profanities. They are how we "do" pain.

The suggestion is only half in jest. Where open source has taken over from closed systems, it has allowed us to create and recreate new and better ways of working – the modern pipeline would be impossible otherwise. Where we communicate our pain with each other, the community improves. Pain is part of that, and it deserves to be liberated from its role as a tool of marketing and returned to the community as a channel of signalling, identifying and fixing problems. Next time you call a YAM file a fatherless son of a canine, you could be doing the world a favour. In fact, I'd swear to it. ®