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.

Continue reading →

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 →

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 →

Originally published on DZone
There’s not much buzz about design patterns these days. They appear to have joined the hall of fame of accepted wisdom, alongside the Silver Bullet, SOLID and DRY. Lately, I had the opportunity to share some thoughts on the importance of good old design patterns with Koen Aerts, CTO of Team Rockstars IT. Here’s the gist of that talk in a more digestible format.

Before I start, let me set some boundaries, as people can get doctrinaire about definitions. I refer to the good old bridge, builder, decorator, and factory patterns. Architectural patterns like MVC do not fall into the same category, much fewer paradigms like serverless and microservices (aka SOA the next generation).

Then again, the latter do constitute a legitimate grey area. They’re clearly about design, patterns, and best practices as well. They offer standard solutions to common challenges. But what makes them different is the scale at which they operate. Classic design patterns are recipes for manageable bits of code, solutions that often fit in a single screen. They explain how to stack the bricks for your new house, whereas microservices show you how to lay out the entire neighborhood.

Continue reading →