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.
In a previous post I wrote about the uncompromising artistry of Stanley Kubrick, who produced film classics at the cost of wildly unpredictable schedules and budgets. You can reach for similar brilliance in programming, but you had better do it on your own time or with a generous CFO. There is a different, more workable, and healthier attitude towards our craft. Just keep at it, enjoy it, and don’t worry about making a dent in the universe. Reading Woody Allen’s autobiography over the holidays, indulge me to draw another cinematic parallel with this veteran New York writer/director. Don’t worry, it will also be about coding.
Woody Allen (1935) is one of the most consistently prolific cinematographers in the business. He has written and directed over fifty films over an equal number of years, almost like clockwork and at 85 shows no intention of stopping. He doesn’t approach his oeuvre as a project with a culmination. His business is about keeping busy. He is in it for the long run, if only to act as an antidote to the unavoidable spectre of death and oblivion. But let’s not get into his glum outlook on life here.
Let’s talk about artistry, craftsmanship and software quality. Writing code has been compared to an art as well as a craft. I love discussing the difference between the two and their relationship to quality. Software quality is a multi-faceted beast (functional correctness, usability, maintainability and all the other ilities). It’s impossible to judge the quality of a program by only looking at its source code, but it’s easy to recognise a clear lack of quality from any illegible tangle of spaghetti. Tools for quality metrics can point to such potential trouble but won’t guarantee that you’re building the right thing.
Anyway, if you take pride in your work, you don’t need tools to keep you on the straight and narrow. A true craftswoman always does the best she can. There is no such thing as too much quality, is there? Perhaps talk to the person who’s putting up the money. Quality saves money later, but it will cost you right now. From a business perspective the product needs to make money long enough to justify that expense. From an artistic perspective none of that matters. The true artist pursues quality for its own sake. Allow me a little segue into film and music.
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.
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.
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.
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.
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.
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.
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.