The irresistibly unbearable Steve and Rob

Ricky Gervais cemented his comic talent in 2005 with the two-season series Extras, in which struggling actor Andy Millman keeps himself and the dream of a real acting career alive with freelance gigs as a movie extra. Each episode he rubs cold shoulders with a genuine star for some truly unforgettable awkward moments. Kate Winslet, Samuel L. Jackson, David Bowie, and Ian McKellen were all game. The bit where Diana ‘Miss Emma Peel’ Rigg gets a condom (albeit unused) flung into her hair by teenager Daniel Radcliffe amazingly sounds far grosser in words than it looked on screen.

Under this genre of celebrity embarrassment porn – a term I just made up – you may class the films that veteran Michael Winterbottom made with his favourite comedian Steve Coogan. It started with The Trip in 2010. Steve is asked to write a series of culinary reviews for the prestigious Observer newspaper and takes along his old friend and fellow comedian Rob Brydon for the trip. In between footage of busy kitchen staff dousing steaming pots of scallops with alcohol, our heroes sit around, eat, bicker, and laugh in a barely adult effort to outwit and outsmart each other. There’s a hundred minutes of the stuff per serving, with not much more plot to go round.

Continue reading

True Component-Testing of the GUI With Karate Mock Server

(previously published on DZone)
In my previous post, I discussed the difference between tests that target code versus those that target an API. A subset of the second category are automated tests for a web/mobile interface that mimic user behavior and validate the rendered responses, using Cucumber/SeleniumCypress, or any other stack. These are typically written and executed as end-to-end tests, in that they require a production-like setup of the backend; but that needn’t be the case. GUI tests can turn into true component tests if they target the browser, but with a fully mocked backend. In a complex microservices architecture, it makes good sense to do so. In this article, I will highlight the motivation for writing those tests, and in a follow-up, I will give tips and examples on how to do so with the Karate framework. Feel free to dig into its excellent document if you can’t wait.

image by Snapwire through Pexels.
Continue reading

Testing Under the Hood Or Behind the Wheel

In a room full of architects, no two will agree about their exact job description, as the joke goes. In a similar vein, someone in our team had a refreshing solution to another persistent bone of contention: how do you define an integration test? Don’t try to reconcile differing opinions and just stop using the term altogether. I liked it very much. Rather than think of unit and integration tests, it’s more helpful to distinguish between tests that validate code versus ones that validate public interfaces and recognize that within each category the scope varies for each individual test.

Continue reading

Public Sector Services Don’t Care About Happy Customers

I started my programming career without a proper computer science qualification, which wasn’t exceptional in the Netherlands in the wild years preceding the dotcom boom. A sensible dose of the impostor syndrome and a lucky sense of how best to fill the knowledge gaps has stood me in good stead. Starting out as a glorified amateur myself, I have always sympathized with the poor end user, perhaps out of a sense of my own bewilderment with all this needless complexity. I was an early fan of Jakob Nielsen’s Alertbox column, who started writing about (web) usability since the nineties.

I don’t think there has ever been a time when computers and software had the same gentle learning curve as using a toaster. Certainly not in the 1950s, when programmer and user were the same person, i.e., an engineer. Dedicated systems remained far from idiot proof long after that and took considerable (memorization) skills to master. Before barcode scanners became common, checkout operators at German ALDI supermarkets had to enter all prices from memory (items had no price tags). It must have been a steep learning curve, but it sure was fast! Such mental feats were required less than a generation ago for a job we would now classify as unskilled labour.

Photo by
Continue reading

Specialists Are Not Cogs in the Machine

Previously published on DZone

In a recent article, I argued that it is becoming even harder to be a credible full stack developer, one who is sufficiently up to date to contribute to every stage of developing a modern web- and/or mobile-based application. You’re not expected to build it all by yourself, obviously, but given enough time and with a little help from Stack Overflow, you could.

Such requirements were not unrealistic in the year 2000. In a typical LAMP-stack app (Linux, Apache, MySQL, Perl) you hand-coded most of your HTML and CSS. JavaScript was still optional and frameworks that kept all presentation concerns on the browser had yet to arrive. The backend created the views and besides a few indispensable modules (CGI, DB), standard Perl did the trick. 

True, a battle was raging between competing web “standards,” with proprietary goodies like Explorer’s marquee tag and Netscape’s layers. But otherwise, the stack was reassuringly stable and manageable. The necessary tools on your belt didn’t weigh you down. And we just built simpler things back then, before the internet became indispensable. Today’s demands for scaling and security are much higher.

Continue reading

Did We Build The Right Thing? That’s What UAT Is About.

Previously published on DZone
There are reasons to give key stakeholders the opportunity to officially sign off on a new software release. We need some formal approval from the people who commissioned it, or at least their delegates. This last stage prior to release is commonly called the user-acceptance test and executed in a UAT environment. It’s an indispensable stage, but treating it as the final step in testing is problematic for several reasons. 

Let me start with a car example. Dealerships are generous with free test drives for the same reason that clothing stores let your try on three different shirts. It’s to let the endowment effect do its dirty work: wearing (or driving) something feels more like you already own it. It’s to get a taste for the look and feel, and a catalyst for closing the deal. It’s not about really testing the vehicle — they expect it back unscratched. Toyota doesn’t need their customers taking an active part in their QA process.

Licensed by
Continue reading

How Can We Ever Forget Jim Carrey?

Today I want to talk about remembering and forgetting, and particularly the vast difference between human and computer memory. Popular fiction likes to cling to some flawed analogies, but any AI expert or neuroscientist knows better. The brain doesn’t distinguish between software and hardware. Memories are not pieces of data. You can’t upload them to the cloud. Everything worth remembering is stored associatively and will fade without context. There are no neat folders and drawers in your head to keep work and private affairs organized. If only there were.

Joshua Foer’s Moonwalking with Einstein from 2012 is a respectable piece of immersive and participatory journalism. While researching his book about the workings of human memory he took an active and successful part in memory championships. These are as the name suggests: competitions to store and reproduce random facts against the clock. The winners are experts at creative mnemonics, the age-old practice to connect random facts into a memorable narrative by making links that stick, however far-fetched.

Jim Carrey and Kate Winslet in Eternal Sunshine of the Spotless Mind (c) Focus Features
Continue reading

Keith Jarrett’s Agile Craftsmanship

Many non-technical skills, qualities, and mindsets are part of software craftsmanship. Today I want to talk about two:

  • Resilience
  • Improvisation

Resilience helps us cope with difficulties by not giving up too soon. Improvisation deals with compromise and creativity in the face of the unexpected. The intuition to distinguish negotiable best practices from unchangeable truths is what agility is about. In earlier posts, I drew analogies between people from art and fiction (Stanley KubrickWoody Allen, and Gomer Goof).

Here’s the story of an agile musician I find very inspiring.

© ECM records
Continue reading

Dave Eggers’ World of Autocorrect Is a Hell on Earth

Dave Eggers’ new novel is a darkly comical techno dystopia. The Every (no link: buy it from your local book shop) is the sequel to The Circle. Its eponymous company is an unholy alliance of the major tech behemoths whose names need no mention. The Every is well on its way to wipe out or enslave all competition when our heroine Delaney joins it, on a secret mission to bring down the system from within. But after the first chapters we already know that resistance is futile.

Winston Smith from George Orwell’s Ur-dystopia 1984 likewise knew he did not stand a chance against the omniscient, all-seeing Party. Yet whereas the surveillance technologies that Orwell conceived were science fiction in 1948, most of The Every’s toys are already here or available soon in an Apple Store near you. Every new addictive app is a wolf in sheep’s clothing, adding more data points to your privacy profile. Eggers’ mission as a techno sceptic is anything but subtle.

Continue reading

Things We Still Do, Twenty Years Onward

Previously posted on Dzone
Joel Spolsky’s once prolific blogging output dried up years ago, but Things You Should Never Do, Part I is still a classic after 22 years. He wrote it as an outsider’s postmortem following the first beta release (6) of Netscape’s browser, three years after the previous major release 4. There never was a version 5. The team had decided on a full rewrite, and the resulting delay probably cost them their competitive advantage over Microsoft’s Internet Explorer. 

If Netscape actually had some adult supervision with software industry experience, they might not have shot themselves in the foot so badly”, he closes. 

I like reading computing history and consider to what degree those articles are relevant today. Here’s the gist of the original argument in my own words.

By stalling development on their current product, Netscape appeared to have shut for business, at least from the end user’s perspective. That was strategically disastrous. It made no business sense to abandon their flagship project like that. From a technical standpoint, it was even worse to throw away all working code and start from scratch. Most code is harder to read than to write, but you should always prefer refactoring to rewriting. Full rewrites are no guarantee that you will not introduce the same bugs again, that were so painstakingly discovered and fixed in the old base.

Continue reading