Special Topics in Calamity Programming
When your one-off experience in an organisation makes you a bastion of knowledge in the field.
So I totally ripped off the title from one of my favourite books, Special Topics in Calamity Physics by Marisha Pessl (which I totally recommend you read). Unlike that book, which on the surface is not about physics, this is absolutely about working as a programmer in tech and the nature of discourse that surrounds it. Tuck yourself in and get ready for a few strange sleepytime stories, and if you’re patient enough you’ll find a sort of angry point to it all at the end.
Beauty and the Business Enterprise Agile Scrum Technique
Once upon a time there was a developer who placed himself on the job market and soon found himself inside the grand headquarters of a multinational business. Entangled in the dusty cobwebs of its hierarchical, departmental, compartmental organisational structure, he ignores the chaos silently whirling around him like a bad draft in winter. He was the latest animated cog in the machine and the best he could do was put his head down and grind through whatever requirements were thrown his way.
He was far from his dream position at a fancy startup, with the bright glass walls and the high sun glaring from the bar-fridges stacked to the brim with free beer, and a leader whose passion and vision successfully masked his borderline sociopathic tendencies. But it was a start and he couldn’t complain as long as the bills were being paid on time.
One day a fresh fly hit the tangled web and decided that if they were going to sacrifice their lifeblood to the corporate machine they could at least transform it into something that worked better for themselves.
Fresh out of Agile College and with his management certifications in hand, he sells his masters on BEAST, the fancy new agile methodology for making organisations as ugly and chaotic as how ugly and chaotic they previously were, only with new words. It would solve every problem and all they needed were a few weird tricks.
He told his bosses and then his team that everyone had to get in to their palacial HQ bright and early in order to do what he called a ‘stand up’, which from his understanding is a meeting where the developers on the team reinforce their managers’ trust issues by giving them nonsensical status reports. This was agile though and the BEAST expert mandated it, because the team couldn’t be agile without it.
The certified agile technician mandated further rituals in order to satiate the ever-hungry Agile gods, and so the chaotic but expectable slog through the project requirements was refactored into a chaotic and entirely unpredictable slog through the management’s whims in the form of a ‘sprint’. A sprint, apparently, was a way for the management to change their mind on project scope whenever they wanted instead of committing to a reasonable expectation, while offering no flexibility in kind for their team. The sprint and its measurements provided amazing new tools for management to meticulously tune their team’s performance by firing and reassigning those who couldn’t deliver the baseline amount of story points in their personal velocity score.
So the story went as the misguided Agilist ran through his checklist of ceremonies and rituals, but this is not the story I want to tell you. The self-proclaimed scrum professional was, to any outside observer, inexperienced and naïve, possibly egoistic, and there is nothing new about the story of big companies being scammed into implementing shoddy systems under the guise of them being ‘Agile’. What’s interesting is what the developer did next.
A few months later the developer escaped his personal hell and left for pastures new, landing in the startup he always dreamed of working for. It was bliss and in wanting to share that bliss the developer wrote an angry blog post.
“Agile will destroy your company!” the developer cried as he shared his cautionary tale to the world. Paragraphs and paragraphs of text were devoted to explaining why exactly agile methodologies should be avoided at all costs. It was a harsh criticism, controversial too, and the article drew as much ire as it did support. “That’s because you didn’t do it right!” one commenter said, frustrated and upset that his life’s work was being rubbished on the basis of a bad experience. “That’s what everybody always says about agile!” another responded, seemingly in support of the developer who authored the post. The message sunk in, however, and the values of agile suffered a hit to its credibility as the singular event supported the diaspora of victims of bad management.
In truth, the developer was not aware that he committed the same sin that his previous scrum master did: in having his negative experience of work he then believed that gave him equal, if not greater, expertise, than the person responsible for it. He had learned nothing of agile or scrum, he had only been tricked into believing that he did. The developer grew resentful over time as his first bad experience tainted the flavour of every one that would follow.
It Takes One To Node One
When I was a young whippersnapper like you the internet to me was like the wild prairie. The vast web of Geocities sites, flash animations, P2P apps and progressive jpegs (not the progressive you think of now) was a vast savannah of knowledge just waiting to be Safari’d, Explore’d and ‘Scaped, and you were the snail seeing it load before your eyes at 28 kilobytes a second, after 5 minutes of listening to what today would qualify as top-quality dubstep to get connected.
For in six days the Lord made the heavens and the earth, the sea, and all that is in them, and rested the seventh day as his disciples embedded a scripting language. — Exodus 20:11
The web was dynamic but not as you know it. The birth of JavaScript—a language so bizarre and complex it took Brendan Eich four days longer to implement it than it took God to implement the entire world—was slow to be adopted as browser vendors quarrelled over its identity and standards, as if it had no choice of its own. It wasn’t until the Age of DHTML reached its zenith that JavaScript began to grow and come into its own.
Skip forward some years and the community rabbled and roused over the true potential of their one true language, and so the Tower of BabelJS was constructed from the rubble of previous efforts and Node.JS sought to bring the language to the elemental core of our being: the backend.
It’s a sorry tale for sure. This was not enough to satisfy the aged and weary and the young and weary-because-its-cool, and the magnificently evolved language remained pinned to a standard it no longer significantly upheld. Thus confirming the notions that first impressions are everything and what you are is always what you will be, JavaScript was met with derision and mockery from people who had not cared to observe the extent to which it had grown and matured, and in many ways became beautiful; a curious amalgam of of programming philosophies over the decades. Functional, procedural, prototypal, object-orient…al, with a strong sense of Self.
The myth grew ever harder to dispell as the community converged around improving their ecosystem instead of managing PR, thus vocal opponents were few and far between as their time was spent more productively. And so the reputation of JavaScript being a joke grew ever stronger.
In every case, the cries from the negative contingent were loud and incessant and absurd, and little effort was made to actively engage in the language as it had become, yet despite this their expertise was still seen as more valid.
One wonders if it was so deserving of such relentless ire or if it was tribalism at play.
The Best Thing Since Sliced Arrays
Did you hear about the kid who pushed his stack too much? He finally popped.
It was 2016 and the market was reeling from the lastest technological collapse. The Document Driven Age had hit the peak and thus began the inevitable collapse as consultants worldwide re-architected their solutions from scratch. Relationships between data are no simpler than relationships between people and it turned out that MongoDB was not the one (-to-many) it claimed to be.
“What on earth was I thinking?” asked one consultant as they became lucid, “I was so busy admiring its web-scale that I was blind to our incompatibilities.”
So it was that nobody learned, and the new hotness came and everything remained the same. Enter the mysterious man Satoshi.
For time immemorial mankind—civilisations-unkind—has invoked the higher power to shed light on the cosmic mystery that is our existence and purpose. Witches, wizards, magic, the blockchain, electricity, mana, prayer, meditation, distributed ledgers, marijuana, homeopathy, voodoo, conspiracy theories, Rust, dragons, the Loch Ness Monster and the blockchain have all been called upon to bring rhyme to our reason (or lack thereof, natch).
Satoshi was the latest and greatest in a long succession of great and, inevitably, late. He bestowed the gift of the blockchain upon our fertile land, upon which we could ledge and distribute and spend money without overarching accountability. Naturally the technology was so theoretically diverse that it could solve world peace, prevent starvation, and decentralise it such that alien races light-years away could participate in real time.
People the world over swarmed upon the hype train like it was Noah’s Ark chooching in after a signal failure (practically another act of god for the British amongst them) and just as there was always a use-case for a bread slicer, there was always a use-case for a distributed ledger and an initial coin offering, which was an offering in the sense of a sacrifice rather than a mutual exchange.
Suddenly, everyone was an expert. The mysterious technology nobody previously knew about became something everybody knew about in intimate detail. Snake charmers and snake oil abound. The bubble was yet to burst yet the pushing continued more and more, teasing the breaking point into existence.
Alright, what the fuck was all that except some kind of literary masturbation? You’re probably not asking that question, I’m just putting it into your mouth so I can draw a conclusion.
If you asked me what I felt about a lot of articles these days, I’d tell you I’m fed up of seeing witnesses masquerading as experts. Just because you had a shitty experience in a company that claimed to be organised in a certain way doesn’t mean the entire nature of that system is flawed; just because you had a burger that tasted like shit doesn’t mean the existence of burgers is wrong. Similarly so, just because it sucked to work with something a decade ago doesn’t mean your decade-old insight and cognitive biases towards that are as accurate now as they most likely were then. And on the flip side just because something looks like the latest and greatest doesn’t mean it’s a one-stop solution for everything you can imagine.
Deeper than that, it’s a hell of a lot easier to be negative about stuff than it is to be positive, even to the point where you may very well cling onto a negative assessment that was once true in order to maintain a particular world-view. This article is case-in-point: it was easier to write this than it was to write a bunch of other more positive things.
I love listening to stories about experiences and how things were, they’re informative and often carry a very subtle message as you connect over how things happened for you. I don’t love listening to one-off stories that are twisted into authoritative, absolute advice as if there’s some deeper wisdom in it. It’s experience but it’s not education: knowing what doesn’t go well doesn’t mean you know what does go well, neither does knowing of bad practices make you better educated about better ones. If you really do want to share some authoritative advice, make sure you’ve experienced both the failure and the success because it’s not enough to only see one side of it.
