Lex Parsimonae

Last year, my son introduced me to a podcast called “Black Box Down”.  Each episode is a discussion about an air disaster of some sort, and in the vast majority of cases, the eventual BOOM is preceded by a long sequence of small problems, dealt with poorly, or over-reacted-to until recovery is impossible.

Exceptions are like that.

I’ve been working on getting DataStax / Cassandra installed on a machine running on Hyper-V, and although it’s been a little while since I experienced the joy of Java stack traces, it’s coming back to me in a hurry.  I Just worked through one that turned out to be rooted in my Java version.  It turns out when the installation requirements indicated Java 8 or better, they left out, “but not too much better”.  After a bit of googling, I found a link suggesting I might need to roll back my Java version, and that did, in fact, make things better.  The process to diagnose has left a bit to be desired, though – starting with the epic stack trace..

What might have been better than this?  How about an assertion on startup to flag the Java version as a problem?  Once upon a time, this software was using a contemporary version of Java, and it would never have occurred to any reasonable developer to put an assertion like this in place, but at this point, it would be really helpful.  Do I have any reasonable expectation that this sort of assertion would make it into the source code?  Nope.  I fully expect that anyone expert enough in this package to contribute to it is well aware of the Java version required, so there’s just no benefit to them to include an assertion like this.  Next problem: packages built on packages built on packages, which make it pretty hard to pin down who should really be responsible for calling out the version dependency.

You may be thinking at this point that an IaC or container solution might be helpful, and I agree.  In this particular case, one of the alternatives at my disposal was an Oracle Virtual Box image that was already set up.  I opted out of that because I’ve already set up Hyper-V and Docker Desktop, and I’m concerned about having too many virtualization platforms sparring with one another.  The “bare metal” setup wasn’t ideal right out of the gates, but the silver lining in this case is that I’m learning a ton.

My biggest takeaway from this experience is going to be to “embrace the suck” – paying attention to the frustration and impact on productivity so I can watch for problems like this in software I’m producing.  As always, putting yourself in your users’ shoes will pay dividends, I believe.

Change is afoot once again. We’ve heard a ton about 5G for the last couple years, and we’re just now starting to see this technology emerge in the market. Plenty of pundits have speculated that 5G is going to have the same magnitude of impact as the introduction of the web or the birth of mobile computing. Last week, we saw Facebook launch a major rebranding last week. The Metaverse is coming, powered in part by that same 5G network.

What’s the connection to 5G? Edge computing and experiences. In this article from Ericsson, Peter Linder cites 5G as a key enabler for AR and VR without the use of a tethered PC. Few of us can imagine how our business applications will take advantage of experiences like this, but recall that just a few years ago, we’d have had a hard time imagining the rich mobile applications we take for granted today.

These new experiences aren’t going to take the place of the experiences we’ve got today — they’re going to add to them. If you’re not already seeing the same explosion in channels, that’s coming, too. Partners, new brands, bundled products — all these channels demand access to the capabilities you’ve got, packaged up in new ways.

There’s no way to support this explosion without careful separation of experiences from capabilities. You should never see the mechanisms by which a command is carried out implemented in the same place your customer experiences it!

Spotify has some great experiences enabled by this sort of separation. I was streaming from my desktop PC this week through my “good” speakers (better than my laptop!), but I also had a Spotify window open on my laptop. I just happened to see the play list sync’ed to the laptop screen, and when I clicked next there, my session on my desktop followed right along. Although this is an ultra-simple example, it’s evidence that Spotify is using its interfaces to send Commands to a back-end service — nothing about the session that’s streaming is connected to the commands at all — otherwise, the audio source would have changed!

At this point, a little faith may be required in order to see a need like this in your enterprise, but for those with preparation on their side, I believe a myriad of new experiences will be possible in a few short years.

Last week, I was reminded of a lesson I learned from one of my mentors many years ago: when you’re regression testing, “different” is all you really need to look for.

A little context would probably help, here.  Nearing the end of a sprint, we’d tested the new features in the sprint, but we really weren’t sure whether we had good regression coverage.  Testing from prior sprints had part of the answer, but we couldn’t really afford the time to run all the tests for this sprint and all the tests from our prior sprints.  Thus, the conversation turned to regression testing, automation, and tactics to speed it all up a bit.

The naive approach to regression testing, of course, is to run every test you’ve ever run all over again, checking each value, examining the dots on the i’s and the crosses on the t’s.  It’s absolutely irrefutable and in the absence of automated tools, it’s also completely impractical.  With automated tools, it’s merely incredibly difficult, but fortunately, in most cases, there’s a better way.

Segue back to my years-ago epiphany, in which I was struggling with a similar problem, and the aforementioned mentor gave me a well-aimed shove in the right direction.  He pointed out that once I’d achieved “accepted”, and thus, “good”, all I needed to look for when regression testing was “different”.   All by itself, this didn’t do much to help me, because looking for “different” still sounded like a whole lot of looking.   Combined with the fact that our application was able to produce some artifacts, however, this idea vaulted our testing forward.

Our application, it turned out, supported importing and exporting to and from excel files, so we were able to use this to radically speed up the search for differences — we saved an export from a known good test, and future tests would just import this file, do some stuff, and export it back out again.  At this point, a simple file compare told us whether we’d produced the same output we’d previously validated as “good”.

Armed with this technique, we began looking for other testable artifacts — to the point where we built in some outputs that were used only for testing.  At the time, it was time well spent, because the maturity of testing tools made the alternatives pretty prohibitive.

And what do you do about a difference when you find one?  First reactions notwithstanding, it’s not necessarily a bug.  A difference could arise as a result of an intended change, so it’s not at all unusual to be able to attribute a difference to a change you’re actually looking for; in which case, you throw out the old baseline and replace it with a new one.  Just remember you’ll need to explain each difference every time you find one, which brings me to a final issue you’ll want to sort out if you’re going to use this technique.

Any artifact you want to use in this way must be completely idempotent — that is, when you run through the same steps, you must produce the same output.  This seems like a gimme, but you’ll find that a lot of naturally-occurring artifacts will have non-idempotent values like ID’s, timestamps, machine names, and so on — you’ll need to address these in order to have artifacts you can use effectively for testing.

Once you get past this little hurdle, you’re likely to find this idea powerful and super-easy to live with, and what more can you ask for in regression testing?