Previously published on DZone.

Life means dealing with bad things that may or may not happen. We call them risks. We assess, evaluate, mitigate, accept, and sometimes blithely ignore them. Building complex and original software are inherently risky and the Agile way of working does not fix that. That’s why we need to be true to the value of courage. I’ll start my argument with a refresher on the topic and some practical examples.

The dictionary defines risks as the likelihood of bad things happening. Equally important is the nature and extent of the damage when the risk becomes a reality. The exact balance between probability and consequences is the bread and butter of actuaries at insurance companies. Their models inform them how likely it is that an average dwelling goes up in flames, so they can put a price on the collective risk of their millions of customers. Several houses are certain to burn down each year and their owners need to be reimbursed. It’s a predictable risk.

The Scala World Hiking Trip

This won’t do in aviation or civil engineering. Every lethal incident prompts an investigation to raise the standard and reduce risk up to the point where we are left with black swans only, events so rare and unpredictable you can’t possibly prepare for them. Most airline crashes are the result of these unknown unknowns.

Here’s a more mundane example. At Scala World 2019 I joined the attendees for the traditional pre-conference hike in the English Lake District. I had visited the area before and arrived with waterproof gear and sturdy boots, knowing the terrain and the unpredictable British weather, which even in September can be brutal.

We set off in the sunshine and of course, it had to rain for much of the walk. Several walkers had not read or minded the instruction email, or even checked the weather forecast. Arriving woefully unprepared in cotton jeans and t-shirts, they got thoroughly soaked and a little miserable. But there was safety in numbers. Spare ponchos were shared, and nobody would have been in mortal danger if they had sprained an ankle while clambering over slippery boulders with their inadequate footwear.

Continue reading →

Summary: It’s deceptively simple to enable caching in Spring, but you must investigate actual production usage in order to configure it properly. There are four areas of concern: peak-time load, uniqueness of requests, savings in time and resources, and the longevity of cacheable values. An example project shows these concerns in action.

I like the topic of caching in Java code. It’s a technique where the Platonic world of clean code meets actual usage. You can never tell just by looking at code whether caching is a good idea or unnecessary optimization. You need to measure or at least predict realistic production loads.

Maybe the Spring framework had made it a little too easy. With minimal boilerplate you can configure any managed object to return cached responses upon repeated requests. Call it once to run the method body, call it twice and the framework intervenes and returns the result of the first call. You can (well, must) plug in a full featured third-party implementation like Caffeine or ehcache to enable things like disk overflow and automatic eviction. 

Continue reading →

SUMMARY: There’s plenty of free advice on how to become a better developer. You can safely skip much of it. You’ve probably heard it all before in different guises. Moreover, the huge scope of present-day IT is such that most advice has limited relevance. It’s rarely universally useful, and even if it is, knowing your golden tips doesn’t mean people live by them.

Blogs catering to developers are bursting with well-meaning bullet point lessons on how you too can join the pick of the bunch. Tell-tale warning signs to help you spot slackers, sociopaths and generic time wasters in your team are another favourite. Many of these articles strike me as hunches based on shreds of personal and/or anecdotal evidence. Who are you to take this authoritative tone with me? I can think up my own Ten Commandments of Seven Deadly Sins, easy. It would be a hodgepodge of stuff I experienced first-hand or read, ordered and filtered by my own subconscious preferences, hoping you, the reader, will find it useful. I won’t do it.

Continue reading →

Pair programming has a long and respectable history. None other than Frederic Brooks of Silver Bullet fame practised it as early as 1953. In terms of seniority it makes Scrum, CI/CD and BDD look like recent fads by comparison. But where many teams practise the latter with varying degrees of commitment and consequent success, pair programming has never been popular in any team that I ever worked in. From personal experience I am not surprised. I must have racked up no more than a week of solid pairing during 22 years as a developer, which was more than enough to my taste. What’s more, I wasn’t convinced of the alleged benefits. 

Continue reading →

My first experience with Hashicorp Consul was when I was tasked to take over some minor maintenance of a simple Springboot app to which my predecessor had added this platform. Consul has everything to set up and run a distributed and horizontally scaled application environment (read: microservices). But since we had only one service and one instance of it, deploying Consul was completely unnecessary and only there as a learning exercise. Good old microservices; you’d think they should be past their peak of inflated expectations by now, but I still regularly find them between the must-have requirements for projects in companies that do not strike me as the kind of hyper-scaler for which microservices were invented and intended. But I could be wrong.

Continue reading →

Tomorrow we choose a new Parliament. Parties have shared their positions in their respective programs on all sorts of fundamental and more topical issues that will affect our present and future lives. Some parties have a clear ideological (religious) bent while others are more pragmatic. Whoever you vote for, you effectively support a wide array of positions that may not be all your own and which can often only be fleshed out in a diluted fashion, but that’s what’s democratic coalition government is about. What you certainly can never have as an individual is an informed opinion on everything important.

Continue reading →

Last January I wrote a post on programming just for fun, by way of introducing my new portfolio website aligilo.com. I promised an update, so here goes.
Hobby projects: the word has a derogatory ring to it, but I think they are vital to your relevance as a developer and a way to stay motivated. Maybe you work at a place where you enjoy unlimited freedom to build what you fancy using whatever tools rock your boat, but that’s not how it usually works in the for-profit world. That world doesn’t revolve around you, except in your universe of private projects.

Continue reading →

The book Range by David Epstein is a convincing plea to educate yourself as broadly as you can, and a warning for too much specialisation. Deepening your professional knowledge often comes down to narrowing your outlook, with tunnel vision as the dubious final station. Quantum leaps in innovation have often come about through cross-pollination of disciplines. The most creative minds take the roads less travelled, where their hyper-specialised intellectual peers would never wander.

I am not a genius at anything, but I do consider myself a solid generalist. I can sing, play the piano, and I have mastered some cello and guitar. I make passable photographs and I am not a bad cook. Except for my musical pursuits there is no hobby I have invested as much of my free time in as dramatic writing, especially if you count the literature classes during my English degree as laying the groundwork. I have written three plays that brought me neither fame nor fortune, but a lot of pleasure. And they have given me an unexpected insight into the trade from which I do make a comfortable living.

Continue reading →